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ABSTRACT 


The  feasibility  of  a  computer  based  Information/Training 
Support  System  for  Operational  Patrol  Squadrons  is  examined 
in  detail.  The  historical  development  and  evolutionary 
trends  of  such  a  system  are  reviewed,  current  initiatives 
and  projects  are  explained  and  evaluated,  and  user 
requirements  are  analyzed  in  order  to  make  recommendations 
for  future  development.  The  Aviation  Training  Support 
System  (ATSS)  ,  Naval  Aviation  Logistics  Command  Management 
Information  System  (NALCOMIS) ,  and  proposed  Portable 
Logistics  System  (PLS)  are  cited  as  possible  developmental 
paths  for  future  systems.  These  paths  are  evaluated  in 
terms  of  Patrol  Squadron  requirements,  and  are  presented, 
either  singularly  or  in  combination,  as  feasible 
alternatives.  This  thesis  serves  as  a  comprehensive 
reference  for  decision  makers  involved  in  systems 
development  within  the  United  States  Navy  Patrol  Aviation 


Community. 
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I. 


I  NTaQ  DUCT  ION 


The  United  States  Navy  Patrol  Aviation  (VP)  Community 
has,  for  the  last  40  years,  been  a  vital  and  viable  force  in 
the  defense  of  the  nation.  It  has  grown  from  the  days  of 
the  PBY  or  "Catalina”  scout  aircraft,  to  a  present 
characterized  by  highly  capable,  technically  sophisticated 
"Submarine  Killers".  The  operational  complexity,  and 
therefore  the  management  of  these  operations,  has  also 
become  significantly  mors  difficult  to  comprehend. 

Within  the  Naval  Air  Force,  Maritime  Patrol  Forces  are 
accountable  to  two  major  commands.  Commander  Patrol  Wings 
Atlantic  has  two  active  Wings  consisting  of  six  squadrons 
each,  a  number  of  Heserve  squadrons,  and  a  Fleet  Replacement 
Squadron  (FRS) .  Commander  Patrol  Wings  Pacific  has 
essentially  the  same  make-up.  The  active  Atlantic  Fleet 
units  are  home-ported  in  Brunswick,  Maine  and  in 
Jacksonville,  Florida,  with  the  Replacement  Squadron  also 
located  in  Jacksonville.  The  Pacific  Fleet  units  are 
located  at  Moffett  Field,  California,  and  at  Barbers  Point, 
Hawaii,  with  the  Replacement  Squadron  at  Moffett  Field. 

The  primary  mission  of  these  commands  is  Antisubmarine 
Warfare  (ASW)  ,  with  an  additional  number  of  major 
responsibilities,  including: 


13 


Surveill  ancs ,  Mining,  Anti-Shipping,  communications. 
Intelligence,  and  Search  and  Rescue.  All  Patrol  Squadrons 
currently  fly  the  P-3  "Orion"  aircraft  in  various 
evolutionary  models.  The  newest  model  currently  in  the 
Fleet  is  the  P-3C  Update  II.  Built  cy  Lockheed,  it  is 
accepted  throughout  the  world  as  the  finest  Patrol  aircraft 
available. 

Current  Patrol  Community  operations  are  carried  on 
worldwide  at  a  number  of  deployment  sites.  Atlantic  Fleet 
locations  are  Keflavik,  Iceland;  Bermuda;  Lajes,  Azores; 
Rota,  Spain;  Sigonella,  Sicily;  and  a  number  of  temporary 
detachment  fields.  Pacific  deployment  sites  currently 
include  Adak,  Alaska;  Cubi  Point,  Phillipines;  Kadena, 
Okinawa;  Hisawa,  Japan;  Guam;  and  Diego  Garcia  in  the  Indian 
Ocean . 

The  cost  of  the  diverse  services  of  the  Patrol  Community 
has  recently  run  at  about  one  percent  of  the  Navy's  annual 
expenditures.  [Ref.  t]  In  terms  of  personnel,  each 
squadron's  complement  is  about  360,  of  which  roughly  140  are 
aircrewmen.  When  combined  with  Patrol  Wing  staffs.  Naval 
Air  Station  personnel  and  facilities.  Aviation  Intermediate 
Maintenance  Departments  (AIND) ,  and  Antisubmarine  Warfare 
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Operations  Centers  (ASWOC) 


at  eacn  deployment  site. 


becomes  very  clear  that  the  Navy's  commitment  to  this 
endeavor  is  far-reaching  and  permanent. 

Due  to  the  importance  of  the  community,  especially  the 
individual  Patrol  Squadrons,  it  is  essential  that  those  in 
positions  of  leadership  within  the  community  strive  to 
attain  and  maintain  a  level  of  managerial  control  that  is  on 
the  same  technological  plane  as  the  systems  and  procedures 
employed  by  the  operational  units.  This  ideology  is 
certainly  not  new,  nor  is  it  without  precedent.  Within  the 
Naval  Air  Force,  as  early  as  1972,  computer-based  management 
information  and  control  systems  were  being  introduced  into 
the  operational  Navy.  £ Bef .  2]  Much  has  been  learned  in 
the  past  decade  concerning  the  applicability  of  automated 
systems  to  the  managerial  process.  Significant  gains  have 
been  made  in  discrete  areas,  such  as  automated  training 
support,  but  individual  commands  have  been  greatly  ignored, 
or  at  least  disregarded,  due  to  a  complex  set  of 
circumstances.  Happily,  conditions  affecting  systems 
development  are  not  static,  and  may,  in  the  presence  of 
current  initiatives,  yield  beneficial  new  capabilities  for 
the  units  that  are  currently  in  need.  Onfortunately,  at  the 
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present  time,  these  initiatives  do  not  include  support  for 

individual  Patrol  Squadrons. 

The  purpose  of  this  thesis  is  to  examine  this  situation 
in  detail,  within  the  framework  of  a  system 
feasibility/requirements  review,  and  in  doing  so,  provide 
decision  makers  with  the  detailed  justification  for  severely 
needed  operational  capabilities. 

Chapter  Two  includes  a  comprehensive,  historical 
background  of  ccmputer-based  information/training  support 
systems  in  the  Naval  Air  Force.  Current  initiatives  are 
also  reviewed,  providing  up-to-date  information  for 
discussion  and  analysis. 

Chapter  Three  examines  the  political  and  regulatory 
environment  that  exists  for  systems  development  in  Naval 
Aviation.  Recent  System  Audit  Reports  are  utilized  to 
illustrate  specific  considerations  applicable  to  patrol 
squadron  systems. 

Chapter  Four  provides  an  in-depth  view  of  patrol 
squadron  operations  and  managerial  organization  and 
procedures.  This  chapter  serves  to  develop  justification  of 
need,  by  citing  informational  deficiencies. 
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Chapter  Five  redefines  the  deficiencies  and  needs 
established  in  Chapter  Four  in  terms  of  patrol  squadron 
requirements.  These  functional  requirements  are  developed 
and  discussed,  and  contrasts  are  drawn  to  other  communities. 
Alternatives  which  meet  the  requirements  are  developed  and 
compared  to  systems  currently  in  use  or  in  development,  in 
order  to  determine  to  what  extent  the  current  environment 
satisfies  the  unique  needs  of  Patrol  Squadrons,  and  to 
provide  decision  makers  with  a  clear  picture  of  the  current 
situation. 

Chapter  Six  concludes  the  thesis  by  drawing  conclusions 
from  the  discussion  and  analysis  performed,  and  by  making 
recommendations  based  on  those  conclusions. 


II. 


BACKGROUND 


The  basic  need  for  management  information  systems  in  the 
Patrol  Aviation  community  was  cited  in  the  introduction  to 
this  paper.  This  chapter  surveys  the  development  of  ADP  and 
MIS  in  the  aviation  community  and  provides  an  overview  of 
projects  in  development  at  this  time. 

A.  VERSATILE  TRAINING  SYSTEM  (VTS) 

The  birth  of  management  information  systems  in  the  Naval 
Aviation  community  started  with  the  conception  of  the 
Versatile  Training  Support  System.  The  original  concept  of 
VTS  was  that  of  an  automated  training  support  system 
oriented  solely  toward  training  enlisted  Naval  Aviation 
personnel  to  perform  maintenance  on  aircraft. 

Prior  to  the  installation  of  the  prototype  VTS  at  NAS 
Lamoore,  California  in  1972,  the  assignment,  training,  and 
utilization  of  all  enlisted  aviation  maintenance  personnel 
assigned  to  the  A7-E  Fleet  Replacement  Squadron,  VA-127,  was 
lone  manually.  Consequently,  the  determination  of  billet 
assignment  and  the  specific  training  necessary  to  fully 
qualify  1,000  students  annually  to  fill  a  specific  billet 
required  an  enormous  amount  of  manual  record  keeping  and 
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roncino as  administr ation.  [Ref.  3]  This  manual  procsss  of 
training  administration  thus  resulted  in  the  occasional  loss 
or  misplacement  of  some  personnel  resources  during  the 
assignment,  procsssing,  and  training  period.  The  tasks 
rsrquired  to  accomplish  training  demanded  the  services  of 
many  qualified  Training  Coordinators  and  numerous  man-hours. 
All  rosters,  muster  lists,  schedules,  letters,  and  forms 
necessary  in  the  training  cycle  had  to  generated  manually. 

The  initial  VTS  was  procurred  through  a  competitive 
contra.ct  as  a  turnkey  training  device  under  the  end-item 
clause  of  Defense  Acquisition  Regulations  3.1100.1(a)  and 
SECNAVINST  5236.1a,  par  1.b.2.d.  [ Hef .  4]  In  essence, 
these  regulations  state  that  general  purpose,  commercially 
available  ADP  components  and  the  equipment  created  from 
them,  regardless  of  use,  size,  capacity,  or  price,  are  under 
the  approval  authority  cited  in  the  instructions.  They  also 
state  specific  types  of  automated  data  processing  equipment 
( ADPE)  which  are  exempt  from  the  stated  approval  authority 
and  requirements.  VTS  uses  standard  off-the-shelf  ADPE  but 
was  exempted  from  the  ADPE  approval  requirements  by  the 
Chief  of  Naval  Material  and  was  designated  solely  as  a 
training  device. 
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The  initial  conf iguration  of  the  VIS  at  MS  Lemoore  was 
designed  and  installed  to  support  the  A- 7  FRAMP  Enlisted 
Organizational  ("0")  level  training  program.  After  test, 
evaluation,  and  acceptance  of  the  Lemccre  VTS  system,  the 
second  installation  was  authorized  for  NAS  Cecil  Field, 
Florida.  The  original  concept  of  supporting  only  the  "0" 
level  training  was  expanded  for  Cecil  Field's  Aircraft 
Intermediate  Maintenance  Department  ( AIMD) .  After  user 
acceptance  of  the  Cecil  Field  installation,  the  third  and 
fourth  installations  were  to  support  the  A6-E  enlisted 
organizational  and  intermediate  level  training  programs  at 
NAS  Oceana,  Virginia,  and  at  NAS  whidbey  Island,  Washington. 


Continued 

user 

satisfaction  and  acceptance  of  the 

Versatile 

Training 

System  has  resulted 

in  sixteen  sites 

installed 

or 

being 

installed  at  Naval 

Air  stations.  In 

addition. 

the 

subsurface  community  uses 

a  variant  of  the 

original 

VTS 

to 

support  their  own 

unique  training 

requi remen  ts. 

In  the  Naval  Aviation  community,  what  was  once  known  as 
the  Versatile  Training  System,  is  now  known  as  the  Aviation 
Training  Support  System,  or  ATSS.  The  change  was  initiated 
to  distinguish  between  the  training  support  system  providing 
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service  to  NAVAI3  funded  activities  and  the  system 
by  the  subsurface  community  which  still  uses 
designation. 


utilized 
the  VTS 


3.  AVIATION  TRAINING  SUPPORT  SYSTEM  (ATSS) 

The  Aviation  Training  Support  System  is  virtually  the 
same  as  the  VTS  discussed  previously.  3y  direction  of  the 
CNO,  the  Aviation  Training  Support  System  was  designated  as 
the  standard  Fleet  Replacement  Sguadron  (FRS)  training 
support  system  at  Naval  and  Narine  Corps  Air  Stations.  As 
such,  the  ATSS  has  been  installed  at  the  following 
location  s: 


**  Fleet 

Replacement  Sguadron 

* 

NAS 

Lemoore 

* 

NAS 

Cecil  Field 

* 

NAS 

Oceana 

* 

NAS 

whidbey  Island 

* 

NAS 

Miramar 

* 

NAS 

Jacksonville 

* 

NAS 

Moffett  Field 

* 

NAS 

North  Island 

* 

NAS 

Brunswick 

* 

NAS 

Barbers  Point 

Activities: 
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**  Planned  chief  Naval  Air  Training  Activities 

*  NAS  Corpus  Christie 

*  NAS  Whiting  Field 

*  NAS  3eeville 

*  NAS  Kingsville 

*  NAS  Meridian 

*  NAS  Pensacola 

This  section  will  describe  the  aa  jcr  responsibilities 
and  program  managers  for  the  Aviation  Training  Support 
System,  system  objectives,  and  the  hardware  and  software 
used  in  the  ATSS . 

1 .  Program  Manager  and  Besponsibilitles 

Naval  Air  Systems  Command  (code  4135H)  is  the 
program  manager  for  Naval  Air  Stations  and  NAVWEPCEN ,  China 
Lake  under  the  sponsorship  of  the  head,  OPNAV  Aviation 
Technical  Training  Branch  (OP-592).  [Ref.  5]  NAVAIB 
responsibilities  as  program  manager  include  preparation, 
review,  justification,  and  defense  of  budget  and 
apportionment  estimates  for  the  ATSS  program.  Total  funding 
for  the  ATSS  through  1985  is  29.5  million.  [Ref.  4] 

NAVWEPCEN,  code  3109,  is  the  ATSS  Program  Manager 
responsible  for  the  technical  development  and  implementation 
of  the  ATSS  program. 
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The  Naval  Training  Equipment  Center  (NTZC)  ,  Orlando, 
Florida,  (code  N-43) ,  is  responsible  for  providing  long  tern 
logistic  support. 

The  principal  users  of  the  Aviation  Training  Support 
System  are  the  Naval  Training  Command,  Fleet  Replacement 
Squadrons,  Naval  Aviation  Maintenance  Training  Group 
Detachments, Naval  Air  Station  AIMD's,  and  limited  usage  by 
Operational  Squadrons  during  their  at-home  cycle. 

2 .  System  Objectives 

The  primary  objective  for  the  ATSS  is  to  improve  the 
match  of  total  training  resources  to  the  student  training 
rate  in  an  efficient  and  cost  effective  manner.  To 
accomplish  its  primary  objective,  the  Aviation  Training 
Support  System  was  designed  to  accomplish  the  following: 
[Bef.  6] 

A.  Determine  and  select  the  best  possible  billet  for  each 
enlisted  m?n  based  on  hi?  individual  capabilities, 
prior  experience,  and  training. 

B.  Tailor  an  individual's  training  by  comprehensive 
testing  (i.e.,  diagonostic,  pr?  and  post  test,  PQS, 
CDI,  QAR,  NATOPS,  etc.)  individualized  prescription, 
and  path  specification. 

C.  Provide  individualized  instruction  under  Instructional 
Systems  Development  (ISD)  guidelines. 

D.  Enable  a  course  manager  to  author,  edit,  review,  and 
update  training  materials  on-line. 

E.  Schedule  training  resources  (aircraft,  simulators, 
maintenance  trainers,  personnel,  etc.)  to  meet  total 
training  requirements  and  priorities. 
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?.  Schedule  the  training  to  minimize  consumption  of 
resources. 


G.  Provide  instructors,  training  coordinators,  quota 
control  personnel,  and  supervisors  with  current 
training  progress  and  future  training  needs. 


H.  Provide  on-line  quota  control  capabilities  Required  to 
support  officer  and  enlisted  personnel  training  for  all 
operational  squadrons. 


I.  Prepare  all  training  correspondence  and  personnel 
training  data  required. 


J.  Permit  consideration  of  the  effect  of  a  decision  in 
advance  by  supplying  complete,  accurate,  and  timely 
training  data  tor  use  in  the  planning  and  decision 
making  process. 


K.  Eliminate  from  the  planning  and  decision  making 
processes  the  problems  associated  with  the  use  or 
inconsistent  trainina  data  by  providing  a  means  of 
preparing  and  presenting  training  information  in  a 
complete,  comprehensive  manner. 


L.  Identify,  structure,  and  quantify  significant  past 
relationships  and  forecast  future  trends  based  on 
training  inrormation. 


M .  Merge  resource  and  production  data  to  produce 
significant  measures  of  training  performance, 
facilitate  control  of  costs,  and  facilitate  training 
decisions  with  minimum  processing  of  data. 


N.  Recognize  the  needs  at  all  training  levels  so  that  the 
requirements  of  each  are  met  with  minimum  duplication. 


0.  Reduce  the  time  and  volume  of  information  required  to 
make  training  decisions  by  reporting  to  each  level  only 
the  exception  from  the  standard  norm. 


P.  Prepare  an  individualized  training  program  for  each 
aircrewman  after  comparing  his  training  history  with  a 
standard  training  syllabus  and  allowing  for  Training 
Officer  modifications.  This  sylabus  consists  of  a  list 
of  tasks  the  aircrewman  is  to  perform  in  a  satisfactory 
and  timely  manner. 


Q.  Assist  the  Schedules  Officer  in  scheduling  the 
aircrewman  in  those  assigned  events  and  predict  a 
training  completion  data. 


R.  Interact  with  Resource  Configuration  and  Scheduling 
(RC  AS )  software.  which  has  information  regarding 
resource  availability  and  status. 
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5.  ^n^rare  s-uder.  r  gradecooks  to  track  each  aircrew 
member's  progress  through  the  sylacus. 

3 .  ATSS  Hardware 

The  specific  hardware  configuration  at  any  one  ATSS 
site  7aries  according  to  the  number  of  activities  that  it  is 


supporting.  All  ATSS  hardware  is  Commercial  Off-the-shelf 


(COTS)  equipment  and  is  centered  around  the  Digital 


Equipment  Corporations  (DEC)  PDP-11  family.  A  typical 


hardware  configuration  for  an  ATSS  site  is  described  below 


and  illustrated  in  Figure  1:  [Hef.  5] 


*  PDP  11/70  Central  Processor  with  2K  bytes  of  Cache 
Memory  and  256K  bytes  of  Parity  core  or  MOS  Memory. 
Memory  Management,  Bootstrap/Diagnostic  Loader,  and 
Line  Frequency  Clock. 


♦  Programmable  Asynchronous  16-line  multiplexor  with 
modem  control.  (Jp  to  eight  multiplexors  can  be 

interfaced  with  the  CPU  to  provide  service  to  64 
interactive  display  terminals. 


*  Console  terminal  teletype  (ASB  33  Teletype)  or 

Hard-Copy  printer  (LA36  DECwriter  11).  Both  units 
contain  a  printer  and  keyboard.  The  teletype  also 

includes  a  paper-tape  reader  and  punch. 


*  Disk  Drive  Controller. 


*  Disk  Drives  (2) .  Disk  drives  have  a  formatted  disk 
capacity  ranging  from  88  to  176  megabytes,  depending  on 
the  type. 


*  Magnetic  Tape  Control  Unit. 


*  Nine-Track  Magnetic  Tape  Transport. 


*  High-Speed  Frinter.  Printer  produces  up  to  132  columns 
of  hara-copy  output  at  a  rate  of  300  to  900  lines  per 
minute  using  either  a  64  or  96  character  drum. 


*  tab  Peripheral  System. 
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*  Aiohar.umeric,  Serial,  Hari-ccDy  Printer  Terminals. 
Printer  terminal  allows  132  column  line  to  be  printed 
at  30  characters  per  second  and  accepts  one  to  six  part 
forms  from  3  inches  to  14-7/8  inches  in  width. 

*  Alphanumeric  CRT  Terminals  (up  to  64).  Normally  ADH-3A 
dumb  terminals. 

*  Intercomputer  Communications  System. 

*  256K  bytes  cf  additional  parity/KOS  memory. 

4 .  ATSS  Software 

AT SS  software  can  be  classified  as  System  Support 
Software  and  Aviation  Applications  Software  and  each  will  be 
iiscussed  separately. 

a.  System  Support  Software 

ATSS  utilizes  the  DEC  RSTS/E  operating  system. 
It  allows  multiple  users  to  interact  with  the  system  and  its 
data  structures.  RSTS/I  can  support  up  to  63  users 
simultaneously  processing  data  using  the  BASIC-PLUS,  COBOL, 
BASIC-PLUS-2,  FORTRAN  IV,  APL,  or  RPG  11  language 
processors.  The  ATSS  system  utilizes  BASIC-PLUS  and 
BASIC-PLUS-2  extensivly  although  it  is  also  capable  of 
supporting  FORTRAN  and  COBOL. 

RSTS/E  includes  a  comprehensive  set  of  system 
utilities  for  the  system  manager  and  timesharing  user.  It 
can  support  line  printer  spooling  and  execution  of  up  to 
eight  batch  jobs.  [Ref.  7] 
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The  RSIS/E  operating  system  dynamically 
allocates  processor  time,  memory  space,  file  space  and 
peripherals  to  best  accomodate  changing  work  loads.  It 
allows  jobs  to  run  one  at  a  time  until  it  either  enters  an 
I/O  sta •*■  =  or  exhausts  its  time  quantum  that  was  assigned  to 
it  by  the  system  or  the  system  mrnager.  After  a  job  becomes 
stopped,  the  scheduler  finds  the  next  job  that  is  ready  and 
begins  to  run  that  job  while  interrupt  driven  device 
handlers  are  processing  requested  data  transfers. 

PSTS/E  attempts  to  keep  memory  filled  with  as 
many  jobs  as  possible.  If  a  job  that  is  to  be  run  is  larger 
than  the  available  memory,  the  system  transfers  some  jobs 
out  of  memory  tc  a  temporary  swap  file  until  it  is  their 
turn  to  run  again. 

The  SSTS/E  file  system  provides  a  wide  range  of 
on-line  processing  capabilities.  Files  can  be  accessed 
randomly  or  sequentially  through  BASIC-PLUS ,  or  through  the 
RMS-11  (Record  Management  Services)  subsystem.  Single  and 
multi -key  ISAM  is  optionally  available  with  HHS-11K 
software.  £Bef.  7]  Files  can  be  created,  updated, 
extended,  or  deleted  interactivly  from  the  user's  terminal 
or  under  program  control.  Files  are  protected  from  access  on 
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an  individual,  group,  and  system  basis.  Files  can  also  oe 
accessed  by  many  users  while  being  updated  on-line.  Back-up 
of  files  can  be  done  either  selectivly  or  totally  and  can  be 
accomplished  on-line  without  disrupting  users,  or  offline, 
b.  Aviation  Application  Software 

All  ATSS  application  software  is  written  in 
modular  form  to  facilitate  new  requirements  and  program 
changes.  The  application  software  that  is  used  by  FBS 
squadrons  consists  of  thirteen  modules  or  subsystems 
described  in  the  following  paragraphs.  [Hef.  5] 

(1)  Personnel  Subsystem.  The  Personnel 
subsystem  provides  computerized  personnel  record  support  by 
enabling  users  to  create,  update,  delete,  or  review 
computerized  personnel  records  for  individuals  in  the  user's 
activities.  This  subsystem  also  produces  assorted  output 
listings  such  as  recall  bills,  precedence  lists,  security 
clearance  lists,  billet  assignment  lists,  prospective  gain 
and  loss  reports,  and  work  center  manning  and  training 
deficiency  lists.  At  the  present  time,  this  subsystem  is 
one  of  the  most  widely  used  amoung  operational  VP  sguadrons 
during  their  at-home-cycle. 
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This  subsystem  maintains  an  inventory  of  all  training 
resources  and  their  location  and  facilitates  the  scheduling 
and  usage  of  all  training  resources.  It  also  produces  such 
reports  as  a  Meekly  Training  Schedule,  Instructor 
Qualification  and  Availability  File,  Resource  Utilization 
List,  etc. 

(3)  Personnel  Scheduling  Subsystem.  The 
Personnel  Scheduling  subsystem  allots  either  automatic 
scheduling  of  personnel  for  all  classes  specified  in  a 
particular  curriculum  or  allows  manual  scheduling  to 
oersor.ally  tailor  an  individual's  curriculum  to  meet  a 
specific  need.  It  also  contains  a  module  to  produce  tne 
following  outputs: 


*  Watch  Lists 

*  Weekly  student  Schedules 

*  Class  Musters 

*  Training  Coordinator s-Student  Schedules 

*  Training  Completion  Letters 

(h)  Test  and  Evaluation  Subsystem.  The  Test 
and  Evaluation  subsysytea  (TEVS)  is  an  automated  test  item 
management  system  designed  to  enable  users  to  create. 


verify,  it.  i  aamcnioter  a  test  question  data  base.  It  also 
has  the  capability  to  print  tests  and  associated  answer 
keys,  as  well  as  utilize  an  automatic  scoring  system  called 
the  les t  input  Device  (TID) .  The  on-line  capability  of  this 
suDsysten  allows  immediate  feedback  to  the  accuracy  of  a 
response  and  then  provides  the  student  a  presentation  of 
missed  questions  along  with  a  list  of  suggested  readings. 
T2VS  also  provides  instructors  with  statistical  data  on  the 
test  questions  themselves  and  allows  upgrading  of  the  test 
question  bank  or  changes  in  the  method  of  presentation. 

(5)  Training  Track  Subsystem.  The  Training 
Track  subsystem  provides  for  the  creation  and  management  of 
courses  an i  events  for  the  varied  numbers  of  curriculum  that 
are  necessary  to  train  the  various  types  of  students  at  a 
PRS.  It  allows  the  user  to  define  the  curriculum  for  the 
students  and  to  select  the  billet  for  enlisted  students,  it 
also  allows  the  user  to  obtain  a  squadron  Manning  Report 
that  lists  all  billets  the  Squadron  has  available  and  the 
individuals  filling  those  billets. 

(6)  Gradebook  Subsystem.  The  Gradebook 
subsystem  provides  an  automated  gradebook  management  system 
in  which  student  progress  and  scheduling  information  is 
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It  also  allows  the  user  to  update  and  manage 

computerized  student  gradebooks.  The  outputs  from  this 
subsystem  are  as  follows: 

*  Grade  book  Review 

*  Gradebook  Survey 

*  Class  Gradesheet 

*  Student  Progress  Summary 

*  Individual  Event  Progress  Summary 

*  Gradeslips 

*  Training  Readiness  Report 

*  Event  Disposition  Summary 

*  Flight  Event  Disposition  Breakdown 

(7)  Flight  Data  Management  Subsystem.  The 
Flight  Data  Management  subsysystem  consists  of  four  modules 
that  allow  for  automation  cf  numerous  forms  and  reports  that 
are  required  for  the  management  of  flight  data. 

The  Naval  Flight  Record  (Yellow  sheet) 
Management  module  allows  users  tc  create  a  computerized 
yellow  sheet  record  as  well  as  updating,  reviewing,  or 
deleting  existing  records  in  the  data  base.  The  data  items 
entered  in  the  computerized  Yellow  Sheet  are  sent 
automatically  tc  other  ATSS  subsystems  for  file  update 
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purposes. 

?C  AS  sof-.war 

e  utilizes  A/C 

bur  eau 

number. 

A/C 

type. 

and 

engine  times 

for  update  of 

component  recor 

ds. 

IFAR3 

dat  a 

is  taken 

directly  from 

this 

module 

and 

#autom atica liy  converted  to  the  format  used  in  the  required 
report. 

The  Logbook  Management  Module  allows  the 
user  to  manage  and  report  necessary  flight  statistics  for 
each  aircrew  member.  Career,  fiscal  year,  and  monthly 
statistics  are  maintained  current  to  the  last  day  of  the 
previous  month.  The  following  outputs  are  created  by  this 
module. 

*  Yellow  Sheet  Transmittal  Eeport 

*  Daily  Flight  Activity  Log 

*  Officer  Monthly  Activity  Log 

*  Daily  Aircraft  Log 

*  Monthly  Aircraft  Report 

*  Aircrew  Monthly/Yearly  Flight  Time 

*  Aircrew  Monthly/Yearly  Activity  Sheet 

*  Yellow  Sheet  Data  entry  Status  and  Error  Reports 

*  Average  Monthly  Sortie  Report 

The  Multiple  Sort  module  is  a  report 
formatter  that  allows  the  user  to  generate  a  report  with  any 
of  the  above  information  specified. 
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(8)  RCA3  Subsystem.  The  Resource  Configuration 
and  Scheduling  subsystem  (RCAS)  consists  o£  several  modules 
designed  to  provide  continous  monitoring  of  aircraft, 
simulator,  and  trainer  configuration  and  status.  It  allows 
the  user  to  match  the  training  resource  to  the  type  of 
training  needed  and  provides  for  scheduling  and  management 
of  maintenance  related  actions  for  all  training  resources. 
The  following  outputs  are  generated  by  the  RCAS  subsystem: 

*  A/C  Accounting  and  Status  Reports 

*  SDLM  Scheduling 

*  Engine  Accounting  and  Status  Reports 

*  Technical  Directive  Compliance  Reports 

*  Configured  Item  Osage  and  Screening  Reports 

*  Training  Event/Aircraft  Subsystem  Requirements  Lists 

(9)  Issue  Subsystem.  The  Issue  subsystem 
manages  and  accounts  for  the  vast  numbers  of  training 
materials  necessary  to  train  a  large  number  of  personnel. 
Library  items  (manuals,  specifications,  texts,  etc.)  and 
equipment  (motion  picture  projectors,  slide-tape  systems, 
video  players,  etc.)  accounting  is  automated  to  insure 
maximum  utilization  is  maintained.  VP-31,  the  FRS  at  aoffet 
Field,  Calif.  utilizes  bar  code  readers  and  bar  coded  I.D. 
cards  to  facilitate  this  process. 
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(10)  Weasons  Plat  fora  Tracking  Subsystem.  This 
subsystem  records  and  stores  information  pertinent  to 
weapons  delivery  tactical  training.  Bomb  and  rocket  delivery 
statistics  indicate  the  success  or  failure  of  the  student 
and  the  training  received.  This  suosystem  is  more  applicable 
to  Fighter  and  Attack  aircraft  communities  but  could  be 
modified  to  include  torpedo  delivery  statistics  for  the  P-3 
community. 

(11)  Query  Subsystem.  The  Query  subsystem 
allows  users  to  create  and  format  reports  that  can  access 
any  desired  data  file  (within  security  constraints)  from  the 
ATSS  data  base.  It  consists  of  two  functions;  commands  and 
Specifications.  Commands  allow  the  user  to  tell  the 
subsystem  what  to  do  and  Specifications  allow  the  user  to 
specify  how  the  output  is  to  be  organized,  what  is  desired 
in  the  output,  and  how  it  is  to  be  displayed. 

(12)  PQS  Subsystem.  The  PQS  and  Qualifications 
Management  subsystem  facilitates  the  tracking  of  an 
individuals  PQS  progress  and  generates  exception  reports  for 
individuals  who  have  expired  or  are  about  to  expire  a 
required  recurring  qualification.  It  also  interfaces  with 
other  subsystems  and  automatically  updates  PQS  records  from 
training  events  and  records. 
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(13) 


HITS  A3  Subsystem . 


The  NITHA5  subs/stsa 


provides  the  Chief  of  Naval  Education  and  Training  with  the 
automated  capability  to  manage  and  support  the  total  Navy 
training  effort.  Three  modules  comprise  the  NII2A3 
subsystem;  Master  Course  Reference,  Student  Master,  and 
Training  Summary.  These  modules  are  designed  to  provide  a 
summary  of  all  training  managed  by  the  ATSS  system  and  are 
delivered  to  CNET  on  mag  tape. 

5 .  ATSS  Summary 

The  Aviation  Training  Support  System  was  designed 
solely  to  support  Aviation  Training  Commands  and  Pleet 
Replacement  Squadrons  in  their  training  effort.  The 
applications  that  have  evolved  since  its  inception  have  lent 
themselves  to  other  areas  besides  training  but  governing 
constraints  and  regulations  have  prohibited  the  expansion 
of  ATSS  outside  the  training  environment. 

Operational  squadrons  have  been  allowed  to  utilize 
the  ATSS  on  a  limited  basis.  For  example.  Operational  Patrol 
Squadrons,  upon  return  from  deployement,  are  loaned  one  dumb 
terminal  (ADM-3A)  from  the  FRS,  and  this  constitutes  their 
sole  interface  with  the  system.  All  printers,  storage 
devices,  and  processors  are  maintained  at  the  FRS,  which  is 
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usually  located  some  distance  away  fro®  the  Operational 

Patrol  Squadron  spaces. 

Applications  run  by  Operational  Patrol  squadrons  are 
limited  in  regards  to  the  total  capabilities  of  the  Aviation 
Training  Support  System.  Generally,  the  squadrons  utilize 
the  personnel  subsystem  and  create  Officer  and  Enlisted 
personnel  rosters,  crew  lists,  recall  bills;  etc.,  but  are 
reluctant  to  automate  other  currently  manual  functions 
because  of  the  lack  of  resources,  and  the  necessity  to 
convert  back  to  manual  procedures  when  the  squadron  deploys. 

C.  M  ALCOMIS 

The  Naval  Aviation  Logistics  Command  Management 
Information  System  (NALCOMIS)  is  currently  a  program 
sponsored  by  the  Chief  of  Naval  Operations  (CNO  Codes  OP-51 
and  OP-52)  and  is  under  the  direction  of  the  Naval  Air 
Systems  Command.  Module  1  of  NALCOMIS  is  designed  to  provide 
a  modern  Management  Information  System  at  the  Organizational 
Maintenance  Activity  (OMA) ,  Intermediate  Maintenance 
Activity  (IMA) ,  and  Supply  Support  Center  (SSC)  to  support 
the  Naval  Aviation  Maintenance  Program  (NAMP) .  NALCOMIS  is 
defined  as  "an  automated  management  information  system  which 
will  provide  aviation  maintenance  and  material  managers  with 
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insly,  accurate  and  complete  ir.foraat.icn  cn  which  to  case 
day-to-day  decisions  through:  a  single,  integrated, 
real-time  automated  system  to  provide  timely  support  to 
aviation  maintenance  and  supply  workers,  supervisors  and 
managers,  and  automated  source  data  entry  devices  for 
simplifying  and  improving  data  collection."  Ir.  addition  it 
is  designed  to  provide  "a  means  to  satisfy  the  Naval 
Aviation  Maintenance  Program  raguir ements,  and  data  inputs 
to,  and  or  interface  with,  other  major  Integrated  Logistic 
Support  (ILS)  Systems  in  the  Naval  Aviation  Logistics 
Community".  [He£.  8]  As  indicated  above,  NALCOMIS  Module  1 
is  designed  solely  for  MIS  support  of  OMA,  IMA,  and  Supply 
Support  Center  maintenance  activities  at  both  ship  and  shore 
sites . 


1 .  History  cf  NALCOMIS 


NALCOMIS  is 

the 

culmination  of 

an 

evolutionary 

process 

which  has 

taken 

place  in  the 

naval  aviation 

community 

.  Several  projects  and  programs 

have  been 

conducted 

over  the 

past 

decade  in  an  att 

empt 

to  improve 

aircraft 

readiness 

and 

availability. 

The 

following 

describes 

the  major 

projects/programs  which 

have 

resulted  in 

the  NALCOMIS  Program. 
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The  Carrier  Aircraft  Maintenance  Support  Improvement 
Project  (CAMSI)  was  established  by  the  Chief  of  Naval 
Operations  in  1970  with  the  purpose  of  identifying  priority 
actions  which  would  improve  carrier  aircraft  readiness.  Two 
of  the  significant  findings  of  that  project  were:  [Ref.  9] 

1.  Imnroved  readiness  could  be  achieved  through  increased 
efficiency  in  management  of  functions  associated  with 
shipboard  aircraft  maintenance  and  support. 

2.  The  most  pratical  and  cost  effective  means  of  attaining 

an  essential  level  of  efficiency  in  those  functions 
would  be  through  improved  use  of  Automated  Data 

processing  equipment  (ADPE) . 

In  1972  the  Shipboard  Aviation  Command  Management 
Information  System  (SACOMIS)  was  initiated  as  a  project. 
SACOMIS  was  supported  jointly  oy  the  Naval  Air  Systems 
Command  and  the  Naval  Supply  Systems  Command  with  regard  to 
ADP  policy  and  procedures,  and  respective  maintenance  and 
supply  policies  and  procedures,  with  HQ  MC  representation  for 
Marine  aviation  matters.  A  detailed  task  effort  was 
undertaken  by  a  working  group  comprised  of  the  Management 
System  Development  Office  (MSDO)  and  Fleet  Material  Support 
Office  (FMSO)  .  In  March  1974,  CNO  (OP-91)  gave  concept 

approval  to  the  SACOMIS  ADS  plan.  CNO  (OP-51)  directed  that 
the  SACOMIS  program  be  expanded  to  include  Naval  Air 
•  Stations,  Marine  Aircraft  Groups  (MAGs)  ,  LPHs,  LHAs,  and 
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Marine  Corps  Air  Stations  under  the  new  program  titled 
NALCOMIS.  A  draft  of  the  NALCOMIS  ADS  Plan  was  completed  in 
September  1975  and  as  a  result  of  review  by  appropriate 
Navy/Marine  Corps  Headquarters  Components  staffs,  a  decision 
was  made  to  limit  the  scope  of  the  initial  endeavor  to  the 
support  of  Organizational  Maintenance  Activities, 

Intermediate  Maintenance  Activities,  and  Supply  Support 
Center  functions.  By  memorandum  from  Vice  chief  of  Naval 
Operations  (VCNC)  on  10  June  1976,  the  CNO  designated 
NALCOMIS  a  program  in  accordance  with  OPNAVINST  5000. 42A. 
The  Assistant  Secretary  of  the  Navy  (Financial  Management) 
approved  the  proposed  NALCOMIS  Module  1  concept  by 
Memorandum  for  CNO  (OP-942)  in  February  of  1977  with  the 
following  stipulations:  [Ref.  9] 

*  The  minicomputers  for  the  NALCOMIS  support  will  be 

frocured  as  part  of  the  Shipboard  Nontactical  ADP 
rogram  [SNAP)  acquisition  tc  ensure  overall 
compatability  with  the  Fleet  non-tactical  systems,  and 
commercial  type  minicomputers  will  be  used  at 

non-deployable  cONOS  sites. 

*  No  hardware  will  be  installed  at  any  other  site  until 
the  operational  prototype  system  has  been  approved  by 
the  Navy  Senior  ADP  Policy  Official. 

ADP  hardware/system  software  for  NALCOMIS  are  to  be 
acquired  under  the  Shipboard  Non-tactical  ADP  Program  (SNAP) 
I,  Phase  2.  The  Solicitation  Document  covering  SNAP  I, 
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Phase  2,  was  released  to  vendors  on  2  Septemcer  1930. 
Initial  vendor  proposals  were  received  on  19  January  1981. 
These  are  in  the  evaluation  process  at  this  time  and  the 
proposal  contract  award  target  date  was  14  October  1981.  In 
the  interim  period.  Interdata  7/32  hardware  aas  been 
installed  at  ?MSC  to  enable  the  Central  Design  Activity  to 
proceed  with  application  program  development  and  testing.  In 
addition,  an  Interdata  3220  computer  was  installed  at  the 
field  test  site,  NAS  Willow  Grove,  Pa.  fcr  system  testing  in 
accordance  with  the  NALCOMIS  Module  1  Functionally  Phased 
System  Development  Plan,  prior  to  the  Prototype  Operation. 

2 .  Current  System  Problems 


The  Baseline 

MI  S 

currently 

in  use  at 

the  OMA, 

IMA 

and  SSC  levels  is 

made 

up  of  a 

variety  of 

manual 

data 

collection  procedures. 

manually 

prepared 

messages 

and 

partially  automated  systems.  In  general,  the  problem  with 
the  baseline  system  is  that  the  procedures  for  recording  and 
extracting  management  information  data  at  the  aircraft 
squadron,  intermediate  maintenance  ,  and  supply  support 
center  levels  are  time  consuming,  error-prone,  and  are 
unresponsive  to  the  needs  of  the  local  aviation  maintenance 
and  supply  workers,  supervisors,  and  managers.  The 
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voluminous,  aan uaHy-inscribed  paperwork  can  be  expected  -o 
increase  with  a  corresponding  decrease  in  quality  and  an 
increase  in  the  pro lif iration  of  local  self-help  systems  can 
be  expected  to  continue  under  present  procedures  and 
conditions . 

3 .  System  Objectives 

The  overall  objective  of  the  NALCOMIS  Module  1 
Program  is  to  contribute  to  improved  aircraft  material 
readiness  by  providing  local  maintenance  and  material 
managers  at  the  CM A,  IMA,  and  SSC  levels  with  a  modern, 
responsive  management  information  system.  The  general 
objectives  of  NALCOMIS  are  to:  [Ref.  10] 

1.  Satisfy  real-time  information  requirements  of  the  case 
level  aviation  maintenance  and  material  managers; 

2.  Satisfy  the  data  reporting  requirements  for  up-line 
information  systems; 

3.  Satisfy  mobility  requirements  of  selected  NALCOMIS 
Operational  sites,  specifically  14  cvs,  12  LPHs/LHAs, 
17  MAGs,  and  deployable  aircraft  squadrons  from  52  NASs 
and  NCASs; 

4.  Satisfy  minimum  requirements  for  contincus  operation  of 
the  MIS  in  a  high  readiness  or  mobilization 
environment ; 

The  specific  objectives/benefits  to  be  achieved  and 
realized  by  the  implimentation  of  NALCOMIS  Module  1  are 
listed  below.  [Ref.  10] 

1.  Minimum  reduction  of  two  percent  (2X)  in  the  NMCM  (Not 
Mission  Capable-Maintenance)  rate. 
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2.  Mini redact  icn  of  five  percent  (5*)  in  existing 
(Awaiting  Maintenance)  rate. 


3.  Minimum  reduction  of  three  percent  (3%)  in  the  NMCS 
(Not  Mission  Capable-Supply)  rate. 


4.  Minimum  reduction  of  five  (5  %)  in  the  PMC  (Partial 
Mission  Capable)  rate. 


5.  Reduction  cf  about  2,153  man-year  equivalents  of 
technical  personnel  engaged  in  non-ADP  functions 
supportina  Baseline  system  operations  and  reassignment 
to  other  tasks  within  the  OMA/IMA/SSC  organizations. 


6.  Minimum  reduction  of  twenty  percent  (20*)  in  supply 
response  times. 


7.  Minimum  reduction  of  twenty  percent  (20*)  in  component 
turn-around  time.  . 


8.  Minimum  reduction  of  five  percent  (5*)  in  BCM  (3eyond 
Capability  of  Maintenance)  actions. 


9.  Reduction  of  305  ADP  support  personnel. 


10.  Minimum  reduction  of  twenty  percent  (20*)  in  inventory 
loss  of  components  through  improved  inventory 
accuracy. 


11.  Reduction  of  unmatched  records  through  integration  of 
maintenance  and  supply  data  bases. 


12.  Quality  and  timeliness  improvement  in  data  reported  in 
support  of  Navy  and  DOD  programs. 


4 .  Proposed  Nalcomis  Capabilities 


NALCOMIS  is  currently  scheduled  to  be  implemented 


at  a  total  of  95  sites,  and  is  designed  to  establisn  and 


maintain  an  integrated  data  base  for  use  at  the  local  site 


user  level.  As  indicated  previously,  the  system  will  serve 


the  maintenance  function  at  the  OMA,  IMA,  and  the  associated 


Supply  Support  Center  and  the  scope  of  the  module  1 


functions  are  illustrated  in  figure  2.2. 
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It  will  assist  maintenance  and  supply  management  by 
providing  current  and  accurate  information  upon  which  to 
base  decisions.  In  order  to  achieve  the  objectives  of  the 
program  and  realize  the  benifits  discussed  above,  NALCOhlS 
lodule  1  will  have  the  following  general  capabilities 
discussed  below. 

a.  Automated  Source  Data  Entry 

According  to  the  Automated  Data  System  (ADS) 
Development  Plan,  the  automated  source  data  entry  system 
will  utilize  preposted  data  in  pre-f ormatted  displays  to 
eliminate  entry  of  redundant  data  and  permit  editing  and 
validation  of  added  data.  Ose  of  a  site  oriented 
centralized  data  base  (S0CIDA3)  will  minimize  the  use  of 
costly  manual  records.  Exception  reporting  and  on-line 
real-time  access  is  one  of  the  capabilities  that  is  required 
of  NALCOHIS.  The  data  base  will  be  on-line  24  hours  a  day, 
seven  days  a  week,  with  the  exception  of  scheduled 
maintenance.  In  addition  to  providing  prescribed 
information  as  defined  by  users.  It  will  support  local 
management  with  an  interactive  query  capability  which  will 
provide  information  to  satisfy  one-time  reporting 
information  needs.  It  will  provide  all  managers  with  data 
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■res  i  ccajor.  sc ii :e  which  will  be  maintained  carre.it 
through  real-time  updating  and  query  capability.  OMA,  IMA, 
and  S SC  managers  will  communicate  with  the  common  data  ease 
aid  with  each  other  through  remote  job  entry  devices 
connected  to  a  minicomputer. 

b.  System  Generated  Schedules  and  Reports 
Maintenance  schedules  and  supply  requirements 

may  be  generated  by  the  system  based  on  work  on  hand, 
scheduled  maintenance  requirements,  technical  data 
information,  work  force  and  skills  inventory,  availability 
of  parts,  priorities,  and  funds  status.  Actual  values  can  be 
tracked  against  projections  and  appropriate  management 
intervention  and  judgement  may  be  applied. 

c.  Information  Availability 

Further  capability  of  the  system  will  allow  for 
tracking  of  maintenance  actions  as  they  occur.  Required 
cost  and  statistical  information  can  be  accumulated  as  it 
occurs  and  in  the  detail  desired  by  management.  Accumulated 
costs  and  statistics  will  permit  local  management  to  analyze 
trends  during  the  reporting  period  and  shorten  the  time 
between  the  end  cf  the  reporting  period  and  the  availability 
of  information  to  up-line  users. 
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2.  Interface  with  ether  Systeas 

In  addition  to  the  previously  mentioned 
benefits,  NALCCMIS  will  interface  with  or  provide  data 
incuts  to  other  major  Integrated  Logistic  Support  (IL3) 
systems  in  the  Naval  Aviation  Logistics  Community.  Some  of 
the  specific  systems  with  which  NALCOMIS  will  interface  are 
listed  below  and  illustrated  in  Figure  2.3. 

*  Aeronautical  Repairable  Management  Systems  (ARMS) 

*  Improved  Repairable  Asset  Management  (IRAM)  includes 

-  Closed  Loop  Aeronautical  Management  Program  (CLAMP) 

-  Serialized  High  Cost  Asset  Reporting  Program  (SHARP) 

-  Fleet  Intensified  Repairables  Management  (FIRM) 

*  Maintenance  Data  System  (MDS) 

*  Subsystem  Capability  Impact  Reporting  (SCIR) 

*  Naval  Aviation  Logistics  Analysis  System  (NALDA) 

*  Flight  Readiness  Evaluation  Data  System  (FREDS) 

*  NORS  Improvement  Program  (NIP) 

*  Analytical  Maintenance  Program  (AMP) 

*  Fixed  Allowance  Management/Monitoring  System  (FAMMS) 

*  shipboard  Uniform  Automated  Data  Processing  System-End 
Use  (SUADPS-EU) 

*  Uniform  Automated  Data  Processing  System  for  Stock 
Points  (UADES-SP) 

*  MSDO  Level  II  Supply  System  for  NAS 
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Sines  the  system  is  designed  to  oe  a  totally 
integrated,  interactive  system  users  will  have  access  to  all 
data  residing  in  the  central  data  base  which  is  controlled 
by  the  data  base  management  system.  Each  organization's  data 
will  be  uniquely  identified  to  that  organization, 
facilitating  data  integrity  and  security. 

5 .  NALCOMIS  Software 

The  software  environment  for  NALCOMIS  will  have  to 
be  discussed  in  general  terms  and  required  capabilities 
since  the  system  is  not  yet  operational  and  the  software  is 
not  fully  implemented  on  prototype  systems.  The 

applications  software  will  be  developed  by  the  central 
design  activity  at  Fleet  Material  support  Office, 
Mechanicsburg,  PA.  The  system  software  will  be  procurred 
commercially  as  a  standard  package, 
a.  System  Software 

The  system  software  to  be  implemented  on  the 
NALCOMIS  system  must  at  a  minimum  be  comprised  of  an 
operating  system,  data  base  management  system,  compilers, 
and  utility  packages. 

(1)  Operating  System.  The  requirement  is  for  a 
real-time,  disk  oriented  operating  system  which  supports 
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tulci-prcg ramming  ana  interactive  queries  from  multiple 
users.  It  should  have  the  capability  to  concurrently 
process  real-time  tasks  in  the  foreground  and  batch  programs 
in  the  background.  The  operating  system  and  communications 
controller  will  need  to  be  able  to  support  from  11  to  208 
remote  source  data  entry  terminals  depending  on  the  size  of 
the  NALCOMIS  installation. 

(2)  Data  Ease  Management  System.  The 
requirement  for  a  multi-user,  real-time  capability  drives 
the  requirements  for  an  efficient  data  base  management 
system  (DB  MS)  which  controls  all  communications  between  the 
users  and  the  mass  storage  of  data.  In  addition  to  handling 
the  storage  and  retrieval  of  data,  the  DBMS  must  ensure  data 


integrity. 

security  and 

privacy  of 

data,  and 

data 

independence 

(application 

programs 

independent 

from 

structural 

changes  in  the 

data  base) 

.  The  DBMS 

must 

accomodate  a 

Site-Oriented, 

Centralized 

and  Integrated 

Data 

Base  (SOCIDAB)  which  will  be  accessed  to  meet  on-line 
inquires  from  users  at  the  OMA,  IMA,  and  5 SC  levels, 
utilizing  a  number  of  different  to  access  similar  data.  A 
query  capability  is  another  required  feature  of  the  DBMS. 
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(5)  Comoil srs.  The  compilers  required  must  be 
able  to  support  ANSI  COBOL  as  the  primary  language  and 
FORTRAN  as  a  supplement. 

(4)  Utility  Packages.  The  required  utility 
programs  must  be  able  to  sort  and  merge  data  riles,  and  copy 
data  from  one  medium  to  another.  Report  generators  are  also 
required  in  connection  with  the  formatting  of  data  reports 
in  response  to  queries.  The  utility  programs  may  be  a  part 
of  the  other  system  software  or  may  be  provide  as  a  seperate 
software  package. 

b.  Application  Software 

The  applications  software  for  NALCOMIS  can  be 
broken  down  by  functions  and  described  generally  as 
subsystems  that  support  the  IMA,  OMA,  and  SSC  activities. 

(1)  Flight  Activity.  Primarily  a  data 
collection  function  for  flight  data  in  support  of  scheduled 
maintenance  requirements;  preparation  of  reports  for 
aircraft  log  becks  and  Aeronautical  Equipment  Service 
Records  (AESR) ;  information  needs  of  Navy  Aviation 
Maintenance  Support  Office  (NANSO) ;  and  the  requirements  of 
the  Individual  Flight  Activity  Reporting  System  (IFARS)  and 
the  Flight  Readiness  Evaluation  Data  System  (FREDS) . 
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( - )  da  n  te  —a  ~  ce  or  i  v  _  ~  <’  •  .  2  36 r  v  e  the  o ^  .i  a  r.  u 
IMA  ty  providing  data  on  the  identification  and  approval  of 
a  maintenance  requirement;  operational  status  of  assigned 
aircraft,  engines,  and  ground  support  equipment  (GSE)  ; 
identification  or  all  outstanding  maintenance  against 
aircraft,  engines,  GSE  and  repairable  components;  current 
work  load  of  each  maintenance  aork  center;  the  status  of 
each  maintenance  action;  alerts  of  scheduled  maintenance 
action;  and  establishing  and  maintaining  the  Individual 
Component  Repair  Listing  (ICRL)  . 

(3)  Configuration  Management.  To  serve  the  OMA 
and  IMA  by  maintaining  the  current  configuration  of  the 
aircraft,  engines,  33 S,  and  components;  track  configured 
items;  and  to  maintain  records  of  incorporated  and  not 
incorporated  technical  directives. 

(4)  Maintenance  Personnel  Management.  To 
maintain  the  maintenance  personnel  rcster  and  to  track 
personnel  availability  for  local  and  specific  assignments; 
personnel  qualifications  and  requalif ications  requirements 
and  dates;  on-board  versus  personnel  allowances;  replacement 
personnel  by  skills  and  reporting  dates;  and  to  project 
maintenance  personnel  losses. 
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(5)  Asset  Management.  To  serve  OMA  an  i  IMA  by 

providing  systematic  inventory  and  location  accountability 
of  assigned  aircraft,  GSE  and  test  benches  to  include 
gain/loss  transactions,  inventory  status  change,  and  GSE 
utilization  data  and  subcustody  actons. 

(6)  Supply  Support  Center.  To  process  demands 
for  repairables,  repair  parts  and  consumables  for 
maintenance  actions.  The  supply  management  of  the 
repairables  will  satisfy  OfiA  and  IMA  interface  requirements. 

(7)  Lccal/Up-Line  Reporting.  To  summarize, 
format,  and  transmit  up-line  data  including  Aviation  3~m  and 
MALCOMIS  operating  and  Support  (06S)  data. 

6.  NAIC0MI5  Hardware 

The  NALCCMI3  System  Hardware  Configuration,  which 
will  be  described  below  in  general  terms  since  the  hardware 
contract  has  not  yet  been  awarded,  basically  consists  of  a 
processor  subsystem,  mass  storage  subsystem,  local 
peripheral  subsystem,  and  remote  peripheral  subsystems 
(?igure  2-4).  [Hef.  9] 
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THE  ADPE  FOR  NALCOMS  MODULE  1 
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Figure  2.4 


Proposed  UALCCMIS  Hardware 


Configuration 


a.  Processor  Subsystem 

The  processor  subsystem  consists  of  a  central 
processor  from  the  upper  end  of  available  minicomputers 
which  will  handle  the  NALCOMIS  Module  1  workload.  The 
system  must  support  ANSI  COBOL-74  and  FORTRAN  programs  and 
utilize  a  compatible  DBMS.  It  must  be  capable  of  operating 
in  a  multiprogramming  environment  and  will  need  a  task 
handler  as  well  as  the  system  support  software  described 
earlier.  The  central  processor  must  have  at  least  512K 
bytes  for  system  and  application  programs. 

b.  Mass  Storage  Subsystem 

The  proposed  mass  storage  subsystem  consists  of 
a  disk  controller  with  three  disk  drives  totalling  a  minimum 
of  400  megabytes  of  storage.  These  storage  devices  will 
house  the  SOCIDAB,  systems  software  library,  the 
applications  software  library,  up-line  statistics  that  will 
be  accumulated  on  an  event  oriented  basis,  and  work  and 
temporary  file  space. 

c.  Local  Peripheral  Subsystem 

The  local  peripheral  subsystem  consists  of  a 
tape  controller  with  two  tape  drives,  high  speed 
line- print er,  and  a  card  reader/punch  device.  The  local 
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peripheral  is  ho  ce  provided  r or  '.IALCDMI3  shore-based  sires 

only.  The  local  peripheral  subsystem  for  NALCOMIS  deployaole 
sites  (currently  only  encompassing  ships  and  MAGs  and  not 
deployable  land-based  aircraft  squadrons),  will  be  provided 
with  the  AN/UYK-5  replaceaent  hardware,  and  therefore  shared 
by  the  HALCOMIS  systea. 

The  tape  drives  that  the  systea  will  use  or  have 
access  to  must  be  industry  compatible,  The  magnetic  tape 
storage  medium  will  be  used  for  storage  of  historical  and 
other  file  data  necessary  to  support  analysis  and  other 
programs  which  will  operate  in  a  batch  mode;  as  transaction 
audit  tapes  on  which  the  data  necessary  for  research  and 
audit  to  resolve  system  discrepancies  can  be  retained;  as 
checkpoint  tapes  on  which  the  data  necessary  to  support  a 
restore,  recovery  capability  will  be  stored;  for  recording 
data  to  be  transmitted  to  up-line  users;  for  dumping  disk 
files  to  assist  in  restore  and  recovery  actions  and  for 
reduction  to  hard  copy  if  a  manual  fail-back  posture  is  to 
be  invoked;  and  for  storing  reports  that  are  spooled  to  be 
printed  later  in  a  batch  mode. 
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-■=  Peripheral  Subsystem 

The  remote  peripheral  subsystem  consists  of  a 
front  end  processor/controller  supporting  up  to  16  key 
visual  display  terminals.  Each  of  these  subsystems  will 
have  a  page  printer  with  and  a  floppy  disk  controller  with 
dual  drives  that  have  up  to  2MB  of  storage. 

7 .  NALCOMIS  Summary 

The  NALCOMIS  Module  1  program  is  not  operational  at 
this  time.  NALCOMIS,  as  approved  in  1977,  was  to  be  fully 
implemented  and  operational  by  1986.  However,  system 
development  problems  have  delayed  program  progress  and  it 
now  appears  that  NALCOMIS  Module  1  will  not  be  fully 
implemented  before  1992  at  the  earliest.  [ Ref .  11] 

As  previously  discussed,  NALCOMIS  Module  1  coverage 
entails  a  management  information  system  oriented  soley 
toward  maintenace  functions.  Further  modules  have  yet  to  be 
defined  but  it  is  safe  to  say  that  they  would  not  be 
implemented  until  after  1992.  Therefore,  a  total  management 
information  system  that  not  only  supported  the  maintenance 
effort  but  operations,  administration,  and  training 
functions  as  well  would  not  be  implemented  for  the  next  ten 
to  fifteen  years  at  the  present  rate  of  NALCOMIS 
developmen  t . 
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D.  PORTABLE  LOGISTIC  SUPPORT  (PL3)  SYS IEM 

The  Portable  Logistic  Support  System  is  a  COMNAVAI SLANT 
program  designed  to  provide  an  interim  solution  to  Naval 
Aviation  maintenance  information  needs  during  the  period 
that  NALCOMIS  is  being  developed  and  implemented.  It  is 
strictly  aimed  at  carrier-based  squadrons  ana  does  not 
address  cr  include  land-based  squadrons  that  exist  in  the  VP 
community.  Essentially,  ELS  is  a  functional  extension  of 
existing  automated  systems  and  could  be  re-named 
"Mini-ATSS".  The  Aviation  Training  Support  System,  which  is 
designed  and  installed  as  a  dedicated  training  system, 
contains  the  RCAS  subsystem  described  previously.  RCAS  was 
designed  to  fill  a  need  of  matching  aircrew  and  syllabus 
training  assignments  with  the  correctly  configured  aircraft. 
An  extension  of  RCAS  was  designated  the  Comprehensive  Asset 
Management  System  (CAS)  which  maintains  the  status  of 
aircraft,  engines,  and  selected  aeronautical  equipment 
including  configuration  data.  CAM  was  approved  for  prototype 
evaluation  at  NAS  Cecil  Field,  Florida  and  was  evaluated  as 
being  a  valuable  maintenance  management  tool.  PLS  expands 
the  functional  capability  of  CAM  and  as  described  in  the 
System  Decision  Paper  for  Milestone  1,  provides  both  the 
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r.arcware  and  support  required  for  system  implementation. 

[ 3ef.  12]  In  addition  to  the  maintenance  software,  PLS  will 
incorporate  certain  personnel  and  training  modules  from  the 
Aviation  Training  Support  System. 

1 .  System  Objectives 

The  overall  objective  of  the  PLS  project  as  stated 

in  the  Milestone  1  System  Decision  Paper  is  to:  [Bef.  12] 

Provide  carrier-based  Atlantic  Fleet  squadrons  an  improved 
information  system  to  ease  the  administrative  burden  of 
maintaining  maintenance  and  logistics  data.  At  the  same 
time,  PLS  will  enhance  the  usefullness  of  organizational 
asset  management  data  for  squadrons  and  up-line  managers. 

Two  assumptions  that  were  made  in  developing  the  PLS 
concept  are  most  important  in  light  cf  other  development 
efforts.  The  first  is  that  PLS  will  not  impede  the  NALC02SIS 
development  effort  in  any  way  and  that  PLS  system  life  will 
end  upon  NALCCMIS  implementation.  The  second  major 
assumption  is  that  the  system  must  be  compatible  for  all 
squadrons. 

2.  ?9ftwar? 

The  PLS  system  proposes  to  use  existing  ATS 3 
software  initially  and  provide  additional  enhancements  to 
the  software  by  1983.  The  system  software  would  consist  of 
the  R STS/E  operating  system  discussed  previously.  This  would 
provide  for  maximum  comparability  and  sharing  of  data 
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av.wi; n  the  units  designated  for  the  Portable  Logistics 
Support  system  and  the  Fleet  Heplacement  Squadrons  that 
utilize  the  ATSS.  The  applications  software  will  basically 
consist  of  ATSS  training  and  maintenance  software  with  some 
additional  enhancements  as  listed  below: 

1.  Maintenance  Software 

*  Additions  to  Aircraft  aecord 

*  Enhance  airframe  technical  directive  and  configured 
item  capability 

*  Monthly  Maintenance  Plan 

*  Individual  Material  Beadiness  List  (IMRL) 

■*  PME  calibration 

*  Expand  JCN  Tracking 

*  Uninstalled  engine/component  tracking 

2.  Training  Software 

*  Adapt  Personnel  Subsystem 

*  Event  Scheduling 

*  Training  Track 

*  Gradebook 

3.  PLS  Hardware/System  Configuration 

There  were  many  alternatives  considered  in  the 
formulation  of  the  Milestone  1  System  Decision  Paper  in 
regards  to  system  and  hardware  configuration.  The 
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alternative  that  was  recommended  consists  of  a  distributed 
system  of  micro/mini-computers  that  are  provided  to  each 
squadron,  functional  wing  and  carrier  air  wing.  2ach 
squadron  system  would  be  identical  and  supports  the 
functional  requirements  cf  squadron  users.  Certain  data 
would  be  provided  on  a  routine  basis  to  the  functional  wing 
or  carrier  air  wing  system  depending  on  whether  the  squadron 
was  on  deployment  or  not.  The  wings  would  then  exchange 
data  between  carrier  and  shore  location  for  updating 
specific  aircraft  and  personnel/training  bases.  The 
distributed  PLS  configuration  is  illustrated  in  Figure  2.5. 

The  specific  hardware  to  be  used  as  specified  in  the 
acquisition  strategy  of  the  PLS  Milestone  1  SDP  is  centered 
around  the  DEC  PDP-11  family  cf  mini-computers.  The 
acquisition  strategy  assumes  that  sole  source  procurement 
will  be  allowed  and  that  the  original  VTS  Support  Contract, 
N00123-80-D-0071 ,  will  be  used  to  acquire  48  squadron 
systems  and  12  Wing  systems. 

The  proposed  central  processor  would  be  a  PDP  11/23 
with  256K  bytes  of  main  memory.  This  mini-computer  along 
with  associated  disk  drives  and  controllers  weighs  about  100 
lbs.  and  fits  in  2  cases  about  the  size  of  a  normal  suitcase 
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."lilestone  1  approval  has  not  been  granted. 

The  concepts  presented  with  the  Portable  Logistics 
Support  Project  are  extreaely  valuable  in  solving  the 
inforaation  needs  of  the  total  Naval  Aviation  coaaunity  and 
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QUANTITY  j  DESCRIPTION 

PDP  11/23  CPU,  256  KB,  Line  Clock 
1  MB  floppy  disk 

Serial  Communication  Ports 

134  MB  Winchester  Disk  Drive  and 
Controller 

Optical  Link  Drivers 

Hard  Copy  Terminals 

CRT  Terminals 

Magnetic  Tape  Drive  and  Controller 
(9  Track,  S00  BPI) 

Uninterruptable  Power  Supply 

300  LPM  Printer  and  Controller 


The  PLS  concept. 


not  just  carrier-cased  squadrons.  The  PLS  concept  provides 
automated  information  support  both  at  the  home  base  and 
while  deployed.  The  design  concept  of  using  distributed 
mini-computers  would  allow  for  a  fail-soft  capability  and 
back-up . 


Prototype  PLS  systems  have  already  been  developed 
and  undergone  limited  testing  at  selected  sites.  The  main 
advantage  of  proceeding  with  the  PLS  concept  is  that  it 
could  be  implemented  very  rapidly  and  the  Naval  Aviation 
community  would  not  have  tc  wait  until  1992  to  receive  the 
benefits  of  an  automated  management  information  system. 


3.  CHAPTER  SUMMARY 

This  chapter  summarized  existing  management  information 
systems  and  systems  in  development  at  this  time  for  the 
Naval  Aviation  community.  The  Aviation  Training  Support 
System  is  operational  at  this  time  and  provides  valuable 
support  to  the  Fleet  Replacement  Squadrons  and  Training 
Commands  but  provides  little  assistance  to  Operational 
Squadrons  due  tc  the  limited  access  and  resources  made 
available  to  them.  The  CNO's  restriction  on  the  use  of  ATSS 
for  training  functions  only,  prohibits  operational  squadrons 
from  utilizing  this  valuable  resource  even  though  the 


65 


■".ajcrit/  of  training  that  an  aircrew  aemcer  receives  is 
accomplished  at  the  operational  squadron  after  the 
crewmember  leaves  the  FRS. 

N ALCOMIS  is  an  approved  program  and  a  line  item  in  the 
budget  but  will  not  provide  the  needed  MIS  support  for 
another  ten  years.  The  NALCOMIS  Module  1  concept  is  limited 
to  supporting  only  maintenace  and  supply  information  needs 
and  provides  nc  support  to  the  overall  administrative, 
training,  and  operational  functions. 

The  Portable  Logistic  Support  System  as  a  concept  is 
sound  but  the  acquisition  stategy  does  not  follow  the 
guidelines  and  regulations  governing  A  CPE  procurement.  The 
design  and  logical  functions  that  PLS  would  perform  are  a 
step  in  the  right  direction  in  not  only  satisfying  the  VP 
community  information  needs  but  that  of  all  Naval  Aviation 
whether  carrier- based  or  not. 
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III. 


POLITICAL  AND  RZGOLkZ OR'/  ENVIRONMENT 


The  Information  Systems  development  that  has  taken  place 
in  Naval  Aviation,  and  the  initiatives  being  considered 
currently,  have  tremendous  potential.  They  fail,  however, 
to  specifically  address  the  information  needs  of  the  Patrol 
Aviation  community.  Expansion  cf  current  systems  or 
creation  of  similar  systems  would  implicitly  seem  to  be  the 
logical  or  even  the  most  economically  feasible  approach  to 
take  to  meet  the  perceived  need  of  the  Patrol  Squadrons. 

Unfortunately,  it  is  not  possible  to  simply  take  from 
those  systems  that  have  been  discussed  previously  the 
functions  or  features  that  are  necessary  and  desirable,  and 
utilize  them  in  an  effective,  efficient  manner  at  the  Patrol 
Squadron  level  without  first  understanding  and  then  dealing 
with  two  major  areas  of  consideration. 

First  of  all,  regulatory  considerations  must  be  well 
understood  and  must  be  addressed  with  tremendous  attention 
to  detail.  Government  Procurement  Regulations,  specifically 
those  concerned  with  acquisition  cf  automated  data 
processing  equipment  (ADPE)  ,  are  most  pertinent.  Procedures 
and  regulations  concerning  the  planning,  programming,  and 
budgeting  of  funds  to  bring  about  the  procurement  of  a 
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systrj  ar?  also  important.  it  is  certainly  not  the  intent 
of  this  research  to  completely  educate  the  reader  in  the 
areas  of  ADF  procurement  and  the  PPBS  process.  Development 
of  a  good  understanding  of  how  these  factors  must  be 
addressed  is  unavoidable,  however,  when  reviewing  their 
relationship  with  the  development  of  a  specific  system. 

Secondly,  the  political  environment  in  which  new  systems 
are  conceived,  born,  cloned,  mutated,  or  aborted  is  an  area 
that  must  not  only  be  understood,  but  must  also  be  studied 
continually  and  positively  influenced  at  every  opportunity. 
The  obvious  reasons  fcr  concern  in  the  political  environment 
are  based  on  the  fact  that  no  matter  how  fantastic  a 
proposed  system  might  be,  it  will  never  be  implemented 
without  the  support  and  approval  of  all  cognizant  parties. 
The  ''parties"  concerned  are  not  necessarily  individuals. 
Individual  Commanders,  Program  Managers,  Sponsors,  or  Action 
officers  may  leave  a  significant  mark,  and  in  some  programs 
prove  to  be  the  reason  for  the  short  term  success  or  failure 
of  the  project.  In  the  context  of  the  entire  life-cycle  of 
programs  developed  over  long  periods  of  time,  however,  they 
are  simply  players  in  the  game.  It  is,  rather,  the 
influence  of  entire  programs,  agencies,  and  Commands  that 
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■■  -he  political  er.vi rcnaer.t  i  r.  which  progress  ar.d  new 
ideas  must  either  flourish  or  fail.  This  influence  is 
primarily  created  and  fostered  by  regulatory  and  budgetary 
control. 

0 

This  chapter  discusses  fcoth  the  regulatory 
considerations  and  the  political  environment  that  pertain  to 
the  introduction  of  information  systems  into  Operational 
Patrol  Squadrons.  This  is  accomplished,  initially,  by 
reviewing  two  specific  audit  reports  which  address 
information  system  development  in  Naval  Aviation.  In  this 
context,  it  is  possible  to  gain  a  greater  understanding  as 
to  the  place  that  the  V?  Community  has  taken  in  this 
development.  It  will  serve  as  a  basis  from  which  the 
current  environment  can  be  examined,  in  order  to  develop 
alternatives  for  the  future. 

A.  ATSS  AUDIT 

1 .  In  fro duct ion 

As  was  mentioned  in  the  preceding  chapter,  ATSS  has 
been  used  to  a  limited  extent  by  Operational  VP  Squadrons 
during  their  at-home  cycle.  This  is  possible  due  to  the 
squadrons'  proximity  to  the  ATSS  sites  at  the  Fleet 
Replacement  Squadrons  (FRS)  ,  the  most  active  being  the  site 
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it  MAS  Moffett  Field.  This  limited  usage,  although 
generally  accepted  and  encouraged  by  Fleet  Commanders  and 
developmental  personnel,  is  an  extention  of  the  ATSS  system 
that  is  not  authorized  under  existing  procurement  policies 
ar.d  procedures.  If  this  were  not  the  case,  VP  Squadrons 
would  have  all  the  functions  of  ATSS  available  to  them 
during  their  at-home  cycle,  and  would  surely  support  an 
extention  of  these  capabilities  to  all  operational 
deployment  sites.  However,  due  to  the  method  by  which  ATSS 
was  procured,  and  the  regulations  which  it  is  currently 
operating  under,  the  patrol  squadrons  are  left  without  this 
tremendous  capability,  underscoring  the  need  for  this 
analytical  review. 

This  situation,  and  its  attendent  political  and 
regulatory  complexities,  is  highlighted  in  Naval  Audit 
Service  Audit  Report  D30Q3Q,  "Development  of  the  Aviation 
Training  Support  System,  Naval  Air  Systems  Command",  which 
was  completed  on  September  26,  1980. 

The  objective  of  the  audit  was  to  evaluate  policies, 
procedures,  and  practices  related  to  the  planning, 
development,  and  acquisition  of  the  Aviation  Training 
Support  System.  [aef.  4]  The  review  concentrated  on  the 
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areas  of  planning,  funding,  and  execution,  with  empnasis  on 
compliance  with  procurement  regulations,  integrated 
logistics  support  and  manpower  planning,  and  employment  of 
automated  data  processing  resources. 

The  results  of  the  audit  indicated  that  ATSS 
development  and  acguisition  have  generally  been 
satisfactory.  The  following  areas  were,  however,  mentioned 
as  those  where  improvement  can  be  made: 

1.  opportunities  exist  for  reducing  costs  by  beneficially 
employing  AISS  hardware  and  software  for  requirements 
of  other  related  information  systems  and  by  manning 
operational  sites  with  government  vice  contract 
employees. 

2.  Improvements  can  be  made  in  fund  administration  and  in 
the  integrated  logistic  support  areas  of  planning  and 
configuration  control.  [Hef.  4] 

The  most  significant  item  noted,  in  terms  of 
importance  to  Patrol  Aviation,  is  the  fact  that  ATSS 
capabilities  are  not  fully  used.  Political  and  regulatory 
considerations  are  collectively  responsible  for  this 
situation.  Further  examination  of  these  factors  is 
presented  quite  well  in  the  findings  of  the  audit. 

2 .  Findings 

The  Chief  of  Naval  Operations  (CNO)  has  not 
permitted  full  use  of  ATSS  capabilities  through  expansion 
beyond  the  FRS  level  into  other  training  or  readiness 
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reporting  areas  wnere  equipment  or  software  coaid  be  shared. 
As  a  result,  related  systems  developments  cannot  benefit 
from  an  offshoot  of  ATSS  until  this  is  changed.  CNO's 
refusal  to  expand  ATSS  was  based  cn  the  perceived  need  to 
maintain  ATSS  exemption  status  under  the  Automated  Data 
Processing  Equipment  (ADPE)  acquisition  regulations. 
[Ref.  4]  The  audit  explained  that  this  exemption  is  no 
longer  needed,  because  the  final  10  ATSS  systems  to  be 
purchased  were  ordered  under  a  FY  1980  contract.  It  was 

stated  that  removal  of  the  exemption  status  would  more  than 
benefit  managers  within  and  beyond  the  training  community  by 
providing  more  timely  and  accurate  management  data  on  a  cost 
effective  basis  to  a  wider  range  of  users  than  any  other 
system  could  provide  individually. 

Department  of  the  Navy  policies  and  procedures 
pertaining  to  AEP  systems  specifications,  selection,  and 
acquisition  are  set  forth  in  SECNAVINST  5236. 1A.  [Ref.  13] 
This  instruction  defines  general  purpose,  commercially 
available  ADP  components  and  the  equipment  created  from 
them,  regardless  of  use,  size,  capacity,  or  price,  which  are 
applicable  to  the  cited  approval  authority.  It  also  allows 
for  specific  types  of  ADPE  which  are  exempt  from  the 
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grccuremen t  regulations  upheld  by  the  approval  autnority. 
Sven  though  ATSS  uses  standard  off-the-shelf  ADPE,  the  Chief 
of  Naval  Material  (CNM)  designated  ATSS  as  a  training  device 
and  exempted  it  from  AO  PE  approval  requirements,  eliminating 
the  need  for  many  time  consuming  procurement  practices. 

Naval  Aviaticn  Procurement  funds  (APN)  have  financed 
the  system  from  its  beginning  until  the  present.  During  PY 
1978,  NAVCOMPT  reviewed  the  ATSS  exemption  status  and  ruled 
that  ATSS  was  not  a  training  device  as  defined  by  DOD/Navy 
budget  policy.  NAVCOMPT,  in  conjunction  with  CNO, 
reclassified  ATSS  as  a  computer- assisted  training  system 
within  the  generic  category  of  equipment  configured  solely 
for  training  applications.  NAVCOMPT  authorized  continued 
APN  appropriation  financing  of  ATSS  hardware  and  software, 
predicated  on  ATSS  use  solely  for  aviation  training 
applications  with  no  other  expansion  capabilities.  This  was 
apparently  done  to  ensure  that  program  execution  would  be 
consistent  with  APN  budget  justifications  submitted  to 
Congress. 

During  the  past  four  years,  various  sponsors  have 
initiated  data  processing  systems  which  represent  either  an 
extention  of  ATSS  capabilities  within  the  general  category 
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of  •‘■.raining,  or  applications  oeyond  the  scope  of  training. 
Although  hardware  and  software  duplication  could  be  avoided 
by  sharing  resources  with  ATSS,  OP-592  has  consistently 
denied  use  of  ATSS  resources  for  systems  which  require  the 
expansion  of  ATSS  to  operational  squadrons  (even  for 
training  support) ,  or  which  generate  output  that  is  not 
training  related.  Examples  of  these  include: 

1.  Fleet  Area  Control  and  Surveillance  Facility  (FACSFAC) . 

2.  Tactical  Aviation  Configuration  Organizational 
Management  System  (TACOMS) .  (see  RCAS,  Chapter  2) 

3.  Liberty  Elite. 

4.  Individual  Flight  Activity  Reporting  System  (IFARS) . 

All  of  the  systems  listed  are  logical  extentions  of 
of  the  existing  ATSS.  Three  of  the  systems  provide  primary 
benefits  to  the  training  community  through  scheduling 
training  resources  (FACSFAC)  ,  maintaining  configuration 
status  of  aircraft  used  for  training  purposes  (TACOMS),  and 
monitoring  training  of  operational  squadron  personnel 
(Liberty  Elite) .  IFARS  reporting  is  tremendously  successful 
at  the  FRS  level,  and  would  greatly  enhance  the  timeliness 
and  accuracy  of  information  at  the  individual  squadron 
level.  All  four  systems  illustrate  the  opportunity  for 
eliminating  duplicate  data  collection  and  hardware 
procurement. 
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be  encouraged.  [Ref.  4]  CNO  concurred  and  stated  the 


following: 


At  its  inception,  the  ATSS  (formerly  VTS)  was 
designed  and  developed  tc  satisfy  an  urgent  fleet  training 
requirement  for  the  aviation  community.  The  system  was 
initially  procured  through  a  competitive  contract  as  a 
turnkey  training  device  under  the  end-item  clause  of 
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Defense  Acquisition  Regulations  3.1100.1(a)  an!  SECNA'/INST 
5236.  1  A,  oar.  I.B.2.d.  At  the  time  the  exemption  was 
granted,  A?SS  was  a  valid  training  system  that  contained  a 
computer,  provision?  for  interconnections  with  training 
simulators,  and  logic  components  for  interaction  between 
the  system  and  students  undergoing  training.  However, 
through  the  evolutionary  development  process,  ATSS  has 
beep  Reduced  in  scope  to  the  stage  of  performing  training, 
administration,  ana  management  functions,  as  well  as  the 
primary  function  of  training  aviation  maintenance  and 
aircrew  personnel. 

ATSS ,  as  it  exists  today,  meets  the  intent  and 
scope  of  an  automated  information  system  and  should  be 
managed,  developed,  acquired,  and  funded  under  &DP  rules 
and  regulations.  However,  one  point  must  be  emphasized. 
Regardless  of  ATSS  status,  it  remains  to  be  determined, 
through  detailed  feasibility  studies  and  economic 
analyses,  to  what  extent  other  systems  can  be  accomodated 
and  savings  achieved  without  degrading  the  primary 
function  of  providing  highly  trained  and  qualified  fleet 
replacement  personnel  for  the  aviation  community. 

CNO  will  take  the  necessary  action  to  remove  the 
ATSS  exemption  from  ADPE  regulations  consistent  with  an 
orderly  transition  scheme  so  as  not  to  disrupt  ongoing 
ATSS  efforts.  [Ref.  4] 


B.  NALCOHIS  AUDIT 
1 .  Introduction 

On  June  19,  1981,  the  Naval  Audit  Service  Capital 
Region  released  to  CNO  (OP-OQ8)  and  Commander,  Naval  Air 
Systems  Command  (AIB-08C)  a  draft  finding  from  Audit  D30051- 
"Development  of  the  Naval  Aviation  Logistics  Command 
Hanagement  Information  System*' .  The  finding,  entitled  "The 
need  for  continuing  NALCOHIS  development  is  questionable", 
provides  concise,  up-to-date  information  on  the  status  of 
NALCOHIS  development,  and  provides  strong  justification  for 
a  recommendation  which  would  have  a  tremendous  impact  on  HIS 
development  in  the  Naval  Aviation  community.  [ Bef.  11] 


Daring  aid  October  1961,  the  final  draft  of  Audit 
D30051  was  released  to  CNO.  This  occurred  after  3  months  of 
rebuttal  by  NALCOMIS  and  extensive  reinvestigation  by  Naval 
Audit  Service  auditors.  The  results  of  the  audit  were 
essentially  the  same  after  reexamination,  leaving  the 
auditors  recommendation  essentially  intact.  (Bef.  14] 

As  this  chapter  is  being  written,  CNO  is  in  the 
process  of  reviewing  the  results  of  the  final  audit.  Future 
NALCOMIS  development  will  be  dependent  on  the  events  that 
take  place  in  the  next  few  months.  Only  by  reviewing  the 
audit  findings  can  one  gain  an  appreciation  of  the  factors 
involved  in  plotting  a  developmental  course  for  the  ruture, 
which  will  have  a  direct  effect  on  the  needs  and  eventually 
the  capabilities  of  Naval  Aviation. 

2 .  Findings 

The  Naval  Aviation  Logistics  Command  Management 
Information  System  (NALCOMIS)  is  intended  to  provide  the 
Naval  Aviation  community  with  a  standard  automated 
information  system  that  will  assist  managers  in 
accomplishing  aviation  maintenance  and  supply  functions,  and 
should  result  in  increased  aircraft  mission  capability, 
increased  personnnel  effectiveness,  and  improved  data 
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reporting.  It  is  not  designed  to  handle  all  or  the 
information  needs  of  an  individual  squadron,  but  vould  give 
squadron  commanders  access  to  a  tremendous  amount  of 
information,  unavailable  before,  which  could  eventually  be 
instituted  into  a  squadron  MIS. 

However,  after  nine  years  of  development  effort 
costing  $22.2  million,  the  auditors  have  determined  that 
little  progress  has  been  made.  It  is  estimated  that 
completion  and  implementation  of  the  system  will  require  at 
least  11  more  years  of  effort  and  additional  life  cycle 
investment  costs  of  $307.8  million.  [Bef.  11]  In  view  of 
these  factors  of  time  and  money,  the  need  for  further 
NALCOMIS  development,  as  presently  envisioned,  was 
determined  to  be  questionable. 

The  auditors'  basis  for  these  estimates  was  based  on 
their  examination  of  the  management  information  systems 
being  developed  at  Naval  Weapons  Center,  China  Lake, 
California  (NAVWENCEN)  under  the  sponsorship  of  commander. 
Naval  Air  Force  Atlantic  (CCMNA 7AI2LANT) .  It  was  felt  that 
these  systems,  already  in  operation  or  final  stages  of 
development,  are  capable  of  fulfilling  NALCOMIS  objectives. 
It  was  further  stated  that  by  incorporating  the  features  of 
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these  systems  in  place  of  continued  development,  the  Navy 
could  expedite  implementation  of  of  the  management 
information  system  objectives  by  at  least  8  years;  reduce 
l^fe  cycle  investment  costs  at  least  $217.8  million,  or  over 
70%;  and  provide  the  aircraft  community  a  more  managable  and 
versatile  system.  [Bef.  11] 

The  N  AVH £ NCEN  systems  examined  are,  interestingly, 
all  offshoots  of  the  ATSS  concept.  The  systems  cited  in  the 
audit  include: 

CAMS  -  Comprehensive  Asset  Management  System 

ECAMS  -  F/A-18  Enhanced  Comprehensive  Asset  Management 
System 

IBIS  -  Interactive  Resource  Information  system 

PLS  -  Portable  Logistics  System 

TACOMS-  Tactical  Aviation  Configuration  Organizational 
Maintenance  System 

A  general  review  indicated  that  modules  (applications)  of 
these  systems  line  up  with  and  provide  essentially  the  same 
information  intended  to  be  procured  by  the  NALCOMIS 
subsystems,  as  listed  in  Table  I. 

The  completed  NAVHPNCEN  systems  are  installed  and 
currently  operating  satisfactorily  at  11  of  the  sites 
designated  for  conversion  to  NALCOMIS  Module  I.  These  sites 
include  nine  naval  air  stations,  an  aircraft  carrier,  and 
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N ALCOMI S  / *3 AVWP NCT : I  MIS  Functional  Comoanson 


NALCOMIS 
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management 


Maintenance 
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Asset  Management 


Supply  support 
center 
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personnel 

Local/upline 

reports 

System  support 
(SNAP) 


COMNAVAIRLANT  svs terns 


Modules/ applications 

Engine  and  airframe 
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airframe,  technical 
directive 
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VIDS/MAF-SAF  2/ 

Avionics 

Ground  support  equipment, 
airframe 

Supply  support 

Maintenance  personnel 
Local/upline  report 


Status 


-  Operational 

-  Operational 

-  Operational 

-  Development 

-  Operational 

-  Development 

-  Operational 

-  Operational 


System  support  (PDP  11/23)  -  To  be 

acquired 


1/  All  NALCOMIS  subsystems  under  development 

2/  Visual  Information  Display  System/Maintenance  Action 
Form  -  Support  Action  Form 


30 


the  NAV rt’PNCEN .  Cognizant  development  activity  personnel 
said  that  further  systems  requirements  that  may  be  needed  to 
fully  satisfy  NALCGMIS  objectives  would  present  no 
development  difficulties.  £Eef.  11] 

The  element  of  the  timeliness  of  NALCOMIS 
implementation#  versus  that  of  the  NA  VWPNCEN  developments, 
and  the  relative  costs  of  the  two  concepts,  were  highlighted 
in  the  audit  findings. 

In  regards  to  the  implementation  time,  systems 
development  problems,  as  discussed  in  Chapter  2,  have 
delayed  program  progress  and  it  now  appears  that  NALCOMIS 
Module  I  can  not  be  implemented  before  FY  1992  at  the 
earliest.  Onlike  NALCOMIS,  site  preparation  and  activation 
for  NAVWPNCEN  management  information  systems  does  not 
involve  extensive  renovations;  shipboard  installations  can 
be  done  at  sea  as  they  do  not  require  the  ship  to  be  in 
overhaul.  Auditors  were  advised  that  NAVWPNCEN  system 
phase-in  could  proceed  immediately  and  cover  all  afloat  and 
ashore  sites  within  3  years.  It  was  also  stated  that  any 
work  needed  to  develop/refine  software  to  meet  NALCOMIS 
requirements  not  presently  covered  could  be  completed  during 
system  phase-in. 
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The  relative  cost  differencial  cf  5217.3  million  in 
life  cycle  costs  that  the  auditors  predict  as  minimum 
savings  if  NA VWPNCEN  systeas  were  used  in  lieu  of  NALCOMIS 
Module  I  were  gleaned  from  the  cost  categories 
systen/pro ject  management,  ADP  hardware,  system  test  and 
evaluation,  and  site  activation.  The  audit  review  in  these 
areas  showed  the  following  cost  differentials  favoring  the 
NAVWPNCEN  systems; 

1.  System/project  management  costs  could  be  reduced  by 
$6.8  million. 

2.  ADP  hardware  costs  could  be  reduced  by  $169.3  million. 

3.  System  test  and  evaluation  costs  could  be  reduced  by 
$23.1  million. 

4.  Site  activation  costs  could  be  reduced  by  $18.6 
million. 


3 .  Summary 


The  auditors  findings 
summarized  quite  well  in  the 
regulatory  requirements  and 
contained  in  the  auditors  words 


and  overall  observations  are 
following  paragraph.  Both 
political  inferences  are 
strengthening  the  position 


of  the  authors  as  to  the  importance  of  these  factors: 


SECNAVINST  5231.1A  and  OPNAVINST  5231.1  provide 
standards  for  managing  and  justifying  automated  data 
systems  from  inception  through  full  operation.  The 
standards  require  that  the  system  be  capable  of  meeting 
its  objectives,  be  the  most  effective  and  econ-  mical  means 
of  satisfying  the  requirement,  and  be  acle  to  be 
implemented  within  a  reasonable  period  of  time.  The 
NAVHPNCEN  mangement  information  system  appears  superior  to 
NALCOMIS  when  judged  by  these  standards.  As  developed,  it 
provides  a  reasonable  framework  that  can  be  expanded  or 
refined  as  required  to  meet  the  objectives  set  forth  for 
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NALCOMIS  at  a  much  lower  life  cycle  investment  cost. 
I jtDle mentation  of  this  system  in  place  of  NALCOMIS  would 
save  the  Navy  a  minimum  of  $217.8  million.  The  NAVWPNCEN 
system  also  can  be  fully  implemented  and  operational  eight 
years  earlier  than  NALCOMIS.  Throughout  its  history, 
NALCOMIS  has  been  justified  on  the  basis  of  urgent  need. 
However,  nine  years  have  passed  since  the  Navy  initiated 
efforts  in  FT  1972  to  automate  information  covering  the 
functions  associated  with  aircraft  maintenance  and 
support.  It  appears  unreasonable  that  the  aircraft 
community  should  have  to  wait  another  9  to  1 1  years  until 
FY  1990  or  FY  1992,  or  18  to  20  years  overall,  to  begin 
obtaining  the  automated  aviation  maintenance  information 
system  benefits  of  a  fully  operational  NALCOMIS  when  the 
need  can  be  satisfied  much  earlier  by  using  another 
system .  [ Ref.  11  ] 


4 .  Recommendation 


Based  on  their  findings,  the  Naval  Audit  Service 


recommended  in  both  their  draft  audit  finding  and  in  their 
final  audit  report  that  CNO  discontinue  further  NALCOMIS 
Module  I  development.  This  was  recommended  in  favor  of 
utilizing  resources  as  required  to  adapt  NAVWPNCEN 
management  information  systems,  previously  under  the 
sponsorship  of  COMNAVAIRLANT,  for  the  Naval  Aviation 
community*  s  use  in  executing  the  Naval  Aviation  Maintenance 
Program . 


C.  CHAPTER  SUMMARY 

Clearly,  there  exists  a  void  in  Patrol  Community  MIS 
involvement  and  development.  This  developmental  void  in 
automated  information  systems  is  a  direct  result  of  the 
political  and  regulatory  environment  that  has  been 
presented.  Ongoing  development  is,  and  will  continue  to  be. 
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subject  to  tne  same  environment.  Therefore,  it  is 
imperitive  that  Patrol  Aviation  take  on  this  problem  as  a 
Community  to  ensure  that  its  needs  are  addressed  and  met  in 
current  and  future  information  systems  developments.  A 
commitment  to  this  goal  must  be  made  quickly,  because  the 
time  involved  in  the  system  development  process  is  long  and 
the  need  is  immediate.  This  does  not  necessarily  mean  that 
current  developments  will  suffice,  or  that  rapid 
implementation  is  even  politically  or  legally  possible. 
Jfhat  is  clear  is  that  efforts  to  circumvent  accepted  systems 
acquisition  regulations  will  not  be  tolerated,  and  that 
political  support  is  very  dependent  on  the 
cost/effectiveness  of  proposed  systems,  especially  in  view 
of  the  current  economic  environment.  This  view  was 
reinforced,  quite  strongly,  by  the  recommendations  given  in 
the  audit  reports  reviewed.  The  audits  also  illustrated 
some  facts  that  will  become  very  critical  in  developing 
alternatives.  NALCOMIS  development  is,  at  present,  a 
tangible  program  with  economic  justification  and  political 
acceptance,  but  it  is  under  close  scrutiny  as  presently 
envisioned,  which  may  cause  sweeping  changes  to  occur. 
Purther  changes  to  NAICOMIS  could,  depending  on  the  specific 
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aerhods  of  adjustment,  cause  the  system  to  be  implemented 
even  later  than  anticipated  or  could  cut  development  and 
implementation  time  significantly.  Unfortunately,  no  matter 
what  hardware  and  software  is  used,  unless  the  functional 
needs  of  the  squadron  are  met,  the  system  is  not,  by  itself, 
the  answer.  Existing  ATSS  sites  will  continue  to  assist 
operational  squadrons  during  at-home  periods,  but  due  to  a 
lack  of  resources  and  problems  of  mobility,  those  assets 
will  not  satisfy  a  significant  portion  of  of  present  and 
future  at-home  needs,  and  fail  completely  for  deployed 
squadrons. 

Squadron  needs  have,  thus  far,  been  addressed  in  terms 
of  systems  capabilities,  or  more  precisely,  in  terms  of  the 
lack  of  capability  now  available.  In  other  words,  if  a 
squadron  function  has  been  automated  and  implemented  on  a 
specific  system,  it  has  been  implicitly  assumed  that  a 
squadron  information  need  exists,  based  on  the  capability  to 
automate  that  function.  In  order  to  pinpoint  more  exactly 
the  shortcomings  of  present  operations,  and  to  forcast  more 
exactly  the  most  feasible  paths  of  development,  it  is 
essential  that  squadron  needs  be  presented  in  terms  of 
functional  requirements  resulting  from  specific  Patrol 
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Squadron  organization.  This  has  not  beer  ione  in  tae  past. 
Prior  to  this  study,  the  majority  of  developmental  analysis 
regarding  automated  information  systems  in  Naval  Aviation 
have  been  geared  to  carrier-based  squadrons  and  air-wings 
and  may  or  may  not  reflect  VP  needs. 

Chapter  Pour  analyzes  Patrol  Squadron  organization  and 
procedures,  and  cites  specific  deficiencies,  in  order  to 
clarify  and  reinforce  the  essential  informational  needs 
discussed  thus  far. 


IV. 


SQUADRON  ORGANIZATION  AND  f  ROC  EDUR  ES 

In  order  to  establish  a  need  and  subsequently  conduct  a 
feasibility  assessment  for  any  system,  it  is  imperative  that 
one  understand  the  organization  and  its  current  operating 
procedures  in  order  to  derive  user  requirements.  This 
chapter  will  identify  the  Patrol  Squadron  organizational 
structure  and  relationships  and  discuss  current  procedures 
in  order  to  identify  any  deficiencies  that  mignt  exist  in 
its  information  needs. 

A.  SQUADRON  ORGANIZATION 

VP  Squadrons  are  normally  composed  of  an  executive 
branch  consisting  of  the  Commanding  Officer,  Executive 
Officer,  and  from  four  to  six  departments  depending  on  its 
complement  of  LCDRs.  The  departments  are  classified 
according  to  their  functional  areas  of  responsibility 
(Figure  4.1),  and  consist  of: 

1.  Operations  Department 

2.  Training  Department 

3.  Administation  Department 

4.  Saf ety/NATOES  Department 

5.  Maintenance  Department 


COMMANDING 


Figure  4.1  Squadron  Organization 
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In  some  squadrons  the  Training  Department  would  be  a 
division  under  the  Operations  Department  and  the  Command 
Services  division  would  be  a  seperate  department.  The  total 
squadron  complement  of  personnel  is  360,  with  60  Officers 
and  300  Enlisted  personnel.  This  chapter  will  not  attempt 
to  provide  an  in-depth  billet  description  for  all  60 
Officers,  but  will  describe  the  major  departments  and  their 
functional  responsibilities  and  procedures  as  they  exist 
today . 

1 .  Operations  Department 

The  Operations  department  is  headed  by  the 
Operations  officer  and  consist  of  the  Flight,  Tactics, 
Intelligence,  and  Communications  divisions  as  illustated  in 
Figure  4.2. 

In  general,  the  Operations  department  is  responsible 
for  the  conduct  and  documentation  of  all  flight  evolutions 
for  the  squadron.  This  includes  an  extensive  interface  with 
the  Training  and  Maintenance  departments  in  order  that  all 
resources  (personnel  and  aircraft),  are  available  and 
capable  of  carrying  out  successfully  the  multitude  of 
assigned  tasks. 


89 


I 


ASST 

OPERATIONS 

OFFICER 


Figure  4.2  Operations  Department  Organisation 
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The  Flight  division  is  responsible  for  the 
scheduling  of  all  daily  activities  including  ground  training 
events.  It  also  oust  insure  that  the  numerous 
r eports/dccumentation  concerning  these  events  are  carried 
out  in  a  timely  and  accurate  manner. 

The  Tactics  division  is  responsible  for  the  tactical 
training  of  all  combat  aircrew  members  and  the  conduct  of 
all  fleet  exercises  and  operational  flights.  The  Tactics 
division  interfaces  extensivly  with  the  Training  department 
in  this  endevor  and  must  insure  that  all  crewmembers  are 
kept  abreast  of  current  developments  in  the  ASH  arena. 

The  Communications  division  is  responsible  for  the 
custody  and  handling  of  all  classified  material  and  for  the 
proper  procedures  and  protocall  in  regards  to  all  squadron 
communications.  This  includes  the  filing  and  logging  of 
hundreds  of  classified  and  unclassified  messages  along  with 
the  numerous  COHTAC  pubs  that  a  squadron  is  required  to 
have. 

The  Intelligence  division  is  responsible  for  the 
training  of  all  combat  aircr ewmembers  in  regards  to  the 
numerous  intelligence  activities  that  a  7P  squadron  engages 
in . 


91 


2 .  Training  De par* mer.t 

As  mentioned  previously,  the  Training  Department 
interfaces  extensivly  with  the  Operations  department  and  in 
some  squadrons  is  organized  as  a  division  in  the  OPS 
department.  In  general,  the  major  resposibility  of  the 
Training  depart ment/division  is  to  supervise  the  progress  of 
all  aircrewmen  and  to  insure  that  the  squadron  maintains  the 
highest  readiness  possible  at  all  times. 

A  general  Training  organization  as  depicted  in 
Figure  4. 3,  consists  of  Plans  and  Readiness,  NWC 
Weapons/Saf ety ,  AH  Division,  and  Plight  Training. 

All  training  that  is  accomplished  along  wita  all 
individual  and  crew  qualifications  that  must  be  received, 
must  be  documented  in  accordance  with  Squadron,  Wing,  and 
NAVAIR  regulations  and  procedures.  This  enormous  amount  of 
documentation  is  a  necessity  in  order  to  track  and  manage 
effectivly  the  readiness  and  utilization  of  the  dwindling 
number  of  squadron  personnel  resources. 

3 .  Administration  Department 

The  Administration  Department  as  depicted  in  Figure 
4.4,  consists  of  the  Department  head.  Asst.  Admin  officer, 
1st  Lt.  division.  Personnel  Division,  Command  Services 
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In  general,  the 


Division,  and  Zducation  and  Legal  Officers. 

Admin.  Department  is  responsible  for  all  the  routine 
paperwork  and  administrative  procedures  that  are  common  to 
most  organizations.  It  interfaces  with  all  departments  ana 
personnel  in  the  squadron  cn  a  daily  basis. 

The  Personnel  Division  handles  all  enlisted 
personnel  files  and  the  numerous  reports  and  documentation 
that  is  associated  with  them.  The  Admin,  office, super  vised 
by  the  Asst.  Admin.  Officer,  handles  all  officer  files  and 
records.  The  1st.  Lt.  Division  maintains  all  squadron 
spaces  and  is  responsible  for  the  billeting  of  all  personnel 
while  on  deployment  and  all  enlisted  personnel  residing  in 
the  barracks  during  the  at-home  period.  The  Command 
Services  Division  has  been  made  a  separate  department  in 
some  squadrons  and  is  responsible  for  retention  and  career 
counseling.  Public  Affairs,  and  all  social  and  welfare 
functions  for  the  squadron. 

4 .  saf ety/NATOPS  Department 

The  Saf etv/ NATuPS  Department  depicted  in  Figure  4.5, 
is  responsible  for  both  the  ground  and  aircraft  safety 
programs  for  all  personnel  in  the  squadron.  This  department 
interfaces  extensivly  with  the  Training  and  Maintenance 
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Departments  in  regards  to  training  ail  personnel  in  proper 
procedures  and  safety  when  flying  aircraft  and  maintaining 
them  on  the  ground. 

5.  Maintenance...  Department 

The  Maintenance  Departaent  as  depicted  in  Figure 
4.6,  is  the  largest  in  the  sguadron  in  terns  of  personnel 
and  the  handling  and  responsibility  for  squadron  resources. 
The  Maintenance  Departaent  in  regards  to  functions  could  be 
considered  a  self  contained  organization  in  itself  and  has 


its  own  administrative  and  training  sections. 

In  general,  the  responsibilities  of  the  Maintenance 
Department  is  to  maintain  squadron  aircraft  and  ground 
support  equipment  to  support  day-to-day  squadron  operations 


and  to  satisfy  the  objectives  of  the  Naval  Aviation 


Maintenance  Program  (NAMP) .  The  objectives  of  the  NAMP  are 


clearly  stated  in  the  promulgating  instruction.  £Ref.  15] 


"....to  achieve  the  readiness  and  safety  standards 
established  by  the  CNO,  with  optimum  utilization  of 
man-power  facilities,  material,  ana  funds.  This  is  to  be 
accomplished  through  policy  guidance,  technical  direction, 
management,  and  administration  of  all  programs  affecting 
activities  responsible  for  aviation  maintenance,  including 
associated  material  and  equipment.  it  encompasses  the 
repair  of  aeronautical  equipment  and  material  at  the  level 
of  maintenance  which  will  insure  optimum  use  of  resources; 
the  protection  of  weapons  systems  from  corrosive  elements 
through  prosecution  of  an  active  corrosion  control 
program;  and  the  collection,  analysis,  and  use  of 
pertinent  data  in  order  to  ecfectivly  improve  material 
readiness  and  safety,  while  simultaneously  increasing  the 
efficient  and  economical  management  of  human,  monetary, 
and  material  resources." 
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The  squadron  level  of  maintenance  (organizational) 
functions  include  inspection,  servicing,  and  handling  of 
equipment  as  well  as  on-eguipment  corrective  and  preventive 
maintenance  including  removal  and  replacement  of  defective 
parts  and  components.  Incorporation  of  designated  technical 
directives  and  necessary  record  keeping  and  reports  peculiar 
to  organizational  level  maintenance  are  also  functions 
assigned  to  the  squadron  maintenance  department. 

3.  CURRENT  OPERATING  PROCEDURES 

Patrol  Squadron  current  operating  procedures  will  be 
discussed  in  terms  of  the  management  information  support 
that  the  system  currently  offers.  Gorden  B.  Davis  in  his 
book  titled  Management  Information  Systems:  Conceptual 
Foundations.  Structure,  and  Development.  stated  that  MIS 
structure  could  be  based  on  organizational  function  or  be 
based  on  management  activity.  [ Ref .  16]  Management 
activity  refers  to  the  type  or  level  of  support  that  an 
information  system  provides, i.e  transaction  processing, 
operational  control,  management  control,  and  strategic 
planning.  This  discussion  of  operating  procedures  and 
information  flows  will  be  centered  around  organizational 
functions  of  a  VP  Squadron,  but  will  inherently  include 
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•different  levels  of  management  activity.  The  organizational 
functions  discussed  below  closely  follow  the  squadron 
departmental  breakdown  and  consist  of  aircraft  maintenance 
management,  training  management,  adainistrative/personnei 
management,  and  operations  management. 

1 .  Aircraft  Maintenance  Management 

The  squadron  maintenance  activity  in  satisfying  NAHP 
objectives  and  daily  operational  requirements,  performs  both 
scheduled  and  unscheduled  maintenance  activities.  Scheduled 
maintenance  is  composed  of  inspections  (phased,  calendar, 
and  special) ,  scheduled  removal  of  components,  and  technical 
directive  compliance.  Unscheduled  aaintenance  are  those 
efforts  expended  to  correct  aircraft  and  equipment 
malfunctions  in  order  to  meet  operational  and  training 
requirements. 

The  squadron  aaintenance  department  uses  the 
aircraft  logbook,  aeronautical  eguipment  service  records 
(AESB) ,  technical  directives,  periodic  maintenance 
information  cards  (PHIC),  and  flight  activity  information  to 
manage  scheduled  aaintenance  requirements.  Management  of 
unscheduled  aaintenance  is  facilitated  by  usage  of  the  Naval 
Aircraft  Plight  Record  (Yellow  sheet)  and  Visual  Information 
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Display  System/Maintenance  Actions  Forms  (VIDS/MA?) 
submitted  by  flight  crev  and  maintenance  personnel. 

In  the  operation  of  the  existing  maintenance 
management  system,  data  is  collected  on  various  manual, 
hanascribed  forms  cr  grease  boards  located  in  the  various 
work  centers  of  the  maintenance  department.  The  current 
status  of  activity  occuring  in  each  of  these  areas  is 
maintained  by  positioning  these  handscribed  forms  in  the 
VIDS  boards  or  by  updating  the  information  on  the  grease 
boards. 

As  mentioned  previously,  VIDS/MAFS  are  the  main 
record  used  to  control  and  monitor  the  accomplishment  of 
maintenance  actions  at  the  squadron  level.  Fart  of  the  form 
is  detachable  for  insertion  in  the  VIDS  boards.  The  fora  is 
used  to  document  on-eguipment  maintenance  as  veil  as  the 
removal  and  subsequent  processing  of  a  repairable  component 
to  the  Intermediate  maintenance  level.  Subsystem  Capability 
Impact  Reporting  (SCIR)  data  is  also  documented  on  the 
VIDS/MAF  along  with  the  maintenance  action  that  reduced  the 
mission  capability  of  the  equipment.  Additionally,  technical 
directive  compliance  (TDC)  and  equipment  inventory  change 
(gain,  loss,  and  in/out  of  readiness  reporting  status)  is 
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reported  on  the  VILS/MAF.  A  second  manually  inscribed 
source  document  form  is  the  Support  Action  Form  (SAF) ,  used 
for  recording  man-hours  expended  on  repetitive,  non-repair 
tasks  such  as  servicing,  cleaning,  painting  ,etc.  The 
handscribed  completed  forms  are  submitted  to  an  external 
local  data  services  unit  for  processing  and  the  preparation 
of  various  reports  generated  by  the  Maintenance  Data  System 
(MDS) .  The  categories  of  the  reports  generated  are 
preventive  and  corrective  maintenance,  replacement  and 
repair  of  defective  components,  changes  to  equipment 
configuration,  material  transactions,  and  aircraft/GSE 
Subsystem  Capability  Impact  Reporting. 

Configuration  management  at  the  squadron  level 
involves  tracking  selected  components  installed  in 
individual  aircraft  and  maintaining  accounting  of  technical 
directive  compliance  requirements  and  actions.  Updated 
technical  directive  lists  2  (not  incorporated)  and  4 
(incorporated)  are  prepared  and  forwarded  by  the  Naval 
Aviation  Logistics  Center  (NALC)  on  quarterly  basis  to  the 
individual  squadrons  for  verification  and  correction.  The 
lag  in  the  Technical  Directive  Status  Accounting  is  from  one 
to  two  months  and  the  updated  lists  received  by  the  squadron 
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ire  neither  accurate  or  timely  enough  to  enable  effective 
configuration  control.  Numerous  manhours  are  spent  by 
squadron  maintenance  personnel  to  verify  actual 
configuration  against  the  lists  and  technical  directive 
documents.  The  time  lag  in  the  system  results  in  additional 
submission  of  VIDS/MAF's  to  insure  that  previous 
incorporations  are  entered  in  the  data  base. 

The  present  information  flow  that  originates  from 
the  submission  of  a  VIDS/MAF  in  maintenance  control  is 
depicted  in  Figure  4.7. 

As  can  be  seen,  there  are  numerous  verification  and 
manual  transfers  of  the  various  parts  of  the  VIDS/MAF.  The 
probabilities  for  loss/misplacement  of  this  record  are  high 
along  with  the  redundant  duplication  and  recording  of  data 
items  contained  in  this  manual  record. 

Flight  activity  information  and  tracking  originates 
from  the  Naval  Flight  Record  (Yellow  sheet  -  OPNAV  Form 
3760/2B) .  Information  concerning  aircraft  flight  time  and 
individual  crewmember  flight  time  is  handwritten  by  flight 
crew  and  delivered  to  maintenance  control  for  data 
collection.  This  data  is  used  by  maintenance  personnel  to 
schedule  maintenance  relative  to  flight  hour  intervals  and 


103 


i'ure  4.7  Squadron  VIDS/MAF  Information 


to  1c ee p  ":rac)c  cf  where  a  specific  aircraft  is  rn  the 
aaintenance  cycle.  The  data  flow  originating  from  the 
Yellow  Sheet  is  depicted  in  Figure  4.8. 

The  information  contained  in  the  yellow  sheet  is 
transcribed  numerous  times  for  varying  applications  and 
records.  The  squadron  aaintenance  activity  keeps  locally 
prepared  daily  time  sheets  for  data  entry  from  each 
completed  yellow  sheet.  Entries  are  added  or  subtracted  from 
cumulative  totals,  recorded  as  aailey  totals  or  single 
sorties,  or  brought  forward  from  previous  time  sheets. 
Extensive  verification  procedures  are  required  due  to 
numerous  records,  files,  and  status  boards  that  use  the 
information  derived  from  the  yellow  sheet. 

2 .  Training  Management 

The  execution  and  management  of  training  crosses  all 
departmental  boundries  and  affects  all  personnel  in  an 
Operational  Patrol  Sguadron.  There  are  approximately  10 
combat  aircrews  in  a  typical  VP  Squadron  with  12  crewmembers 
per  crew.  Thus,  120  sguadron  members  are  involved  in 
aircrew  training  alone.  In  addition  all  maintenance 
personnel  must  be  trained  in  order  to  accomplish  certain 
tasks  required  of  specific  work  centers.  Although  there  is 
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a  designated  Training  Department  or  Division  in  the  squadron 

organizational  structure,  training  is  also  enacted  and 
managed  by  other  functional  areas  in  the  squadron.  Training 
is  required  to  prepare  all  Officers  and  Enlisted  personnel 
to  fill  certain  ground  jobs  or  billets  in  a  sguadron  in 
addition  to  Saf ety/NATOFS  training,  tactical  training, 
general  military  training  (GHT) ,  substance  abuse  training, 
etc. 

One  of  the  main  objectives  of  an  Operational  Patrol 
Sguadron  during  peacetime  is  to  maintain  the  highest  degree 
of  readiness  possible  at  all  times.  The  primary  means  for 
accomplishing  that  goal  is  through  continous  and  effective 
training.  Thus,  training  equates  to  readiness  and  a  high 
degree  of  readiness  depicts  an  effective  training  program. 

As  mentioned  previously,  the  majority  of  the 
training  that  a  crewmember  receives  in  order  for  him  to 
qualify  for  a  specific  position  on  the  P3  aircraft  is 
accomplished  in  the  operational  squadron  after  he  completes 
the  sylabus  at  the  Fleet  Replacement  Squadron.  This  does 
not  mean  that  the  FSS  is  ineffective  .  The  FRS  is  designed 
to  provide  indoctrination  and  initial  training  to  the  first 
tour  aviator  and  refresher  training  to  the  second  tour 
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aviator.  It  normally  takes  from  1  to  2  years  of  additional 
training  after  the  three  to  six  months  at  the  FES  to  fully 
qualify  the  first  tour  aviator  at  his  final  combat  aircrew 
position.  The  reason  for  the  le.nghty  time  of  additional 
training  in  the  operational  squadron  is  that  the  officer 
crewmembers  must  have  a  knowledge  of  all  12  crew  postions  in 
this  complex  aircraft.  The  following  discussion  will 
describe  the  current  procedures  utilized  to  manage  and  track 
the  training  activities  in  the  operational  Patrol  Squadron. 

Current  tracking  of  training  progress  for  air 
crewmembers  involves  numerous  manual  records  and  files  and 
the  ever  present  manually  updated  grease  board  or  chart.  A 
training  jacket  is  maintained  for  each  of  the  120  air 
cremembers  and  updated  by  the  respective  N FO ,  Pilot,  or 
Enlisted  Aircrew  Training  Officer.  In  addition,  the 
respective  NATOPS  Officer  or  Petty  Officer  maintains  a 
seperate  file  on  all  flight  personnel  to  track  and  record 
their  progress  in  relation  to  NATOPS  exams  and  inflight 
checkrides. 

All  squadrons  have  a  standard  training  syllabus  for 
aircrew  based  on  the  Personnel  Qualification  Standards  (PQS) 
system.  This  system  consists  of  numerous  training 
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objectives  that 


must  be  successfully  completed  ar.d  consist 


of  both  practical  factors  and  flight  evolutions.  Each  of 
these  pratical  factors  must  be  signed  off  by  a  qualified 
instructor  in  a  student  lcgbook  and  on  a  student  gradesheet 
and  then  transcribed  again  in  the  individuals  training 
jacket.  This  redundant  recording  of  information  is  extremely 
time  consuming  and  subject  to  errors.  The  progress  of  each 
crewmember  under  training  is  plotted  on  a  greaseboard  from 
information  obtained  from  the  PQS  logging  and  filing 
procedures.  This  information  is  used  by  plans  and  schedules 
officers  to  determine  the  next  sequence  of  flight  evolutions 
for  a  specific  individual.  The  training  progress  of  an 
individual  is  also  used  by  the  Operations  department  in 
determining  crew  composition  and  crew  manning  projections  in 
addition  to  monthly  readiness  and  training  reports  sent  to 
the  functional  wing.  Thus  it  can  be  seen  that  an  extremely 
accurate  data  base  is  needed  concerning  training  tracking 
and  the  present  manual  method  of  maintaining  that  data  base 
is  time  consuming  and  error  prone. 

MATOPS  training  is  another  area  that  maintains 
extensive  records  and  files  pertaining  to  individual 
qualifications  and  deficiencies.  Plight  crewmembers  are  not 
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legally  qualified  to  perform  as  a  functional  crewmember 
unless  they  hold  a  current  NATOPS  qualification. 
Maintaining  current  NATOPS  qualifications  requires 
successful  completion  both  open  and  closed  boo*  NATOPS 
exams  and  a  NATOPS  flight  check.  Extensive  NATOPS  questions 
banks  must  be  manually  maintained  and  updated  for  eight  cren 
positions;  Pilot,  Tacco,  Nav/Com,  Acoustic  Sensor  Operator, 
Non-Acoustic  Sensor  Operator,  Flight  Engineer,  Flight  Tech., 
and  Ordnanceman. 

All  of  the  manually  maintained  records,  files,  and 
question  banks  mentioned  above  in  regards  to  training 
management  require  numerous  man-hours  that  could  be  used  for 
individual  counseling  and  personalized  training. 


The  current  procedures  in  the  functional  area  of 
Administration  and  Personnel  management  require  numerous 
clerical  man-hours  to  produce  and  edit  the  many  reports, 
files,  and  evaluations  required  of  any  squadron  in  the  J.S. 
Navy.  Operational  Patrol  Squadrons,  as  of  this  date,  do  not 
have  any  word  processing  capability  to  aid  in  this  process. 

As  mentioned  previously,  the  Personnel  Division 
handles  all  Enlisted  personnel  records.  This  is  an  extremely 


large  file  or  manual  data  base  from  which  numerous 
summaries,  reports,  and  lists  must  be  assembled  or 
manipulated.  Some  Operational  VP  Squadrons  do  make  use  of 
the  ATSS  Personnel  nodule  to  a  limited  extent  when  they  are 
not  deployed  and  are  home-based  at  either  NAS  Moffet  Field 
or  NAS  Jacksonville  which  have  ATSS  equiped  FRS .  This 
limited  support  must  be  severed  when  the  squadrons  deploy 
and  all  automated  personnel  functions  must  be  returned  to 
the  manual  data  base.  It  therefore  requires  the  squadron  to 
maintain  both  a  manual  personnel  data  base  and  the  ATSS 
personnel  data  base  (if  desired)  in  order  to  prevent  a 
complete  reconstruct  when  required  to  deploy. 

Watch  lists,  recall  bills,  duty  section  rosters,  3EQ 
billeting  assignments,  social  rosters,  etc,  are  examples  of 
the  numerous  applications  that  must  be  manually  produced  and 
maintained  from  the  personnel  data  base  in  addition  to  the 
personnel  resource  data  such  as  NEC  codes,  gain  and  loss 
accounting,  time-in-rank,  and  time-in-service  that  is  a 
necessity  for  advancement  and  overall  squadron  management. 
All  required  reports,  both  internal  and  external  to  the 
squadron,  are  managed  by  a  manually  maintained  and  monitored 
"tickler  file".  The  reports  that  are  produced  have  to  be 
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typed  in  the  rough,  and  then  chopped  and  edited  numerous 
times  before  the  report  is  authorized  to  lea7e  the  squadron. 
This  results  in  numerous  clerical  man-hours  typing  and 
re-typing  documents  before  they  are  sent  out.  The  manual 
tickler  file  and  the  manually  produced  documents  not  only 
increases  man-hours  but  affects  the  timeliness  of  the 
reports  as  well. 

4 .  Operations  Management 

The  function  of  Operations  management  is  one  of  the 
more  critical  management  areas  in  the  squadron.  aeeting 
committments  and  producing  quality  results  are  extremely 
important  and  "visible”  objectives  of  any  squadron.  Current 
procedures  involvinq  operational  control  receive  little,  if 
any,  automated  support.  Some  squadrons  do  make  use  of  the 
ATSS  in  producing  crew  lists  but  that  is  just  one  small 
application  or  output  of  the  Operations  management  function. 
Operational  control  involves  day  to  day  scheduling,  short 
term  and  long  term  planning,  resource  inventory  control,  and 
up-line  reporting  and  documentation. 

Daily  flight  scheduling  is  currently  accomplished 
using  manually  produced  weekly  and  monthly  ops  and  training 
plans,  personnel  availability  lists,  and  Wing  tasking 
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requirements.  Aii  of  these  manual  inputs  must  ce  balanced 

and  weighed  against  each  other  in  order  to  derive  the  most 
optimum  schedule  possible.  This  manual  process  often  is 
sub-ject  to  human  error  and  poor  input  data  that  results  in 
numerous  flight  schedule  conflicts. 

The  yellow  sheet,  discussed  previously  under 
Maintenance  management,  is  also  used  for  operational  control 
of  flight  hour  usage  and  individual  flight  hour  accounting 
and  recording  (IFARS  data) .  The  data  obtained  from  the 
yellow  sheet  is  transcribed  again  into  individual  logbooks 
and  on  computer  input  forms  for  processing  at  an  external 
activity.  A  single  automated  entry  of  yellow  sheet  data 
would  alleviate  the  many  mistakes  and  omissions  that  result 
from  the  redundant  and  repetitive  procedures  that  currently 
exist . 

Current  procedures  utilized  to  track  sonobuoy  usage 
involves  manual  recording  of  flight  summary  data  and 
periodic  physical  counting  of  exisiting  sonobuoys  both  on 
aircraft  and  in  sonobuoy  stowage  bins.  Numerous  man-hours 
could  be  saved  if  a  single  source  data  entry  procedure  could 
be  utilized  to  track  and  report  these  assets. 
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Up-lin*  management  requires  both  periodic  and 

one-time  status  reports.  The  current  procedures  utilized  to 
summarize  and  format  the  data  required  in  these  reports 
involves  numerous  personnel,  man-hours,  and  manually 
recorded  reports  and  files  to  produce  the  desired  output. 
An  automated  data  base  and  report  formatter  would  greatly 
reduce  the  enormous  amount  of  effort  in  producing  these 
reports  as  well  as  improve  their  accuracy. 

C.  CHAPTER  SUMMARY 

This  chapter  summarized  current  Patrol  Squadron 
organization  and  operating  procedures  concerning 
Maintenance,  Fersonnel/Administr ative.  Training,  and 
Operational  management.  This  is  a  necessity  in  any 
feasibility  study  in  order  to  determine  and  identify  any 
deficiencies  that  might  exist  in  a  particular  system.  The 
deficiencies  that  were  identified  in  this  chapter  will  form 
the  basis  for  stating  the  functional  requirements  that  a 
Patrol  Squadron  Management  Information  System  should 
satisfy. 
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7.  PATROL  SOU  AS  SO  N  REQUIREMENTS  AND  ALTERNATIVES 

A.  INTRODUCTION 

A  cursory  analysis  c f  the  present  patrol  squadron 
information  system  and  its  deficiencies  indicates  that  it  is 
extremely  laborious  and  time-consuming.  It  is  characterized 
by  numerous  handwritten  source  documents;  nonstandard  data 
collection  and  recording  of  information;  completely  manual 
procedures  for  operational  control,  training  support,  and 


personnel  support; 

and  an 

outdated 

data 

processing 

capability,  external 

to  the 

squadron. 

for 

processing 

maintenance  data. 

Output  from  the  current  system  is  neither  timely  nor 
sufficiently  comprehensive  for  squadron  commanders  to  remain 
abreast  of  the  broad  spectrum  of  squadron  information  needs. 
Supplemental  information  requests  by  higher  commands  result 
in  further  manual  data  manipulation,  additional  workload 
burdens,  and  reduced  mission  effectiveness. 

Constrained  decision  making,  that  occurs  due  to  the  lack 
of  timely  information  required  to  support  patrol  squadron 
operations,  is  the  ultimate  result  of  current  procedures. 
This  situation  will  deteriorate  further  because  of 
increasingly  sophisticated  weapons  systems  and  the  expanded 
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data  requirements  needed  for  effective  management  control. 
[  Ref.  12] 

As  mentioned  in  Chapter  Three,  it  is  imperative  that 
decision  makers  within  the  Patrol  community  begin  to  look 
more  and  more  closely  at  Patrol  Aviation  information  systems 
with  an  eye  for  change.  Future  capabilities  and  performance 
will  be  affected  greatly  by  developments  occurring  now  and 
in  the  coming  months. 

Therefore,  prior  to  a  decision  to  develop  a  new  system 
or  to  modify  an  existing  one,  functional  requirements  of  the 
user  should  be  determined.  These  requirements  should  be 
general  in  nature,  but  should  completely  cover  all  phases  of 
Patrol  Squadron  operations.  This  chapter  is  designed  to 
present  the  reader  with  a  good  understanding  of  what  a 
Patrol  Squadron  HIS  should  do,  and  from  that  analysis, 
present  feasible  alternatives  for  the  future.  New  system 
benefits  and  the  costs  of  subsequent  project  phases  are 
highly  dependent  on  the  validity  and  accuracy  of  the 
requirements  determination.  Likewise,  the  quality  of 
alternatives  developed  to  meet  the  requirements  is  subject 
to  the  correctness  of  the  functional  requirements. 
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3.  3ENERAL  FUNCTIONAL  RE QUISEtfENTS 

Chapter  Four  reviewed  existing  methods  and  procedures, 
and  concluded  fcy  describing  functional  activities  which 
exhibited  management  information  deficiencies. 

In  order  to  satisfy  the  cited  areas  of  deficiency,  by 
developing  meaningful  requirements,  it  is  critical  that  the 
analysis  of  these  requirements  be  based  on  direct  contact 
with  users.  Both  authors  have  had  recent  operational  tours 
in  Patrol  Squadrons.  This  experience  has  been  invaluable  in 
relating  to  individual  squadron  personnel  as  well  as  to 
developmental  personnel  in  various  program  billets. 

The  functional  requirements  discussed  in  this  chapter 
are  a  product  of  both  research  and  experience.  The  authors* 
recent  managerial  experience  in  Patrol  Squadron  operational 
control,  aircraft  maintenance,  training,  and  administration, 
and  the  perceptions  developed  and  lessons  learned  from  this 
experience,  were  important  factors  in  the  determination  of 
requirements.  These  necessary,  although  probably  not 
sufficient,  past  experience  and  perceptions  can  be 
supplemented  greatly  by  current  analysis.  For  this  reason. 
It  was  determined  that  specific  squadron  operations  should 
be  examined  with  specific  deficiencies  in  mind. 
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Patrol  Squadron  Forty  Seven,  located  at  doffetr  Field 

Naval  Air  Station,  was  visited  on  August  17,  1981.  The 

objectives  cf  this  research  trip  were: 

1.  Determine  current  squadron  organizational  structure  and 
practices. 


2.  Develop  valid  requirements  for  input,  retained  data, 
and  output  as  compared  to  those  determined  for  Tactical 
Aviation  squadrons  in  the  PLS  System  Decision  Paper, 
and  as  determined  by  current  patrol  squadron 
procedures. 

3.  Investigate  additional  areas  cf  application  for 
automated  information  systems  in  patrol  squadrons, 
based  on  the  perceptions  of  current  squadron  personnel. 

The  outcome  of  the  squadron  visit  was  most  positive. 
Patrol  Squadron  Forty  Seven  proved  to  be  most  receptive 
host,  and  more  importantly,  provided  valuable  data  for 
analysis. 

Due  to  the  fact  that  VP  47  is  located  at  Moffett  Field, 
which  has  an  ATSS  capable  FRS  resident,  its  information 
processing  capability,  however  limited,  is  typical  of  the 
best  available  tc  VP  squadrons.  Through  the  limited  use  of 
ATSS  resources,  personnel  in  the  squadrcn  have  become  aware 
not  only  of  the  potential  of  automated  information  systems, 
but  also  cf  the  frustration  that  can  occur  from  limitations 
imposed  on  facilities  and  on  squadron  usage. 

Interviews  were  conducted  and  data  was  collected  in  the 
functional  areas  of  operations  management,  maintenance 
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management,  -raining  management,  and  per scnnel/aaain 
management.  Typical  system  workload  requirements  were 
obtained  in  the  form  of  primary  inputs,  outputs,  and 
retained  data.  These  charts  assist  greatly  in  translating 
manual  functions  into  automated  information  system 
processing  requirements.  Appendix  A  contains  the  estimated 
system  workload  charts,  which  are  similar  to  the  charts 
developed  in  the  PLS  paper  for  TACAIR  squadrons.  Based  on 
this  research,  the  functional  requirements  which  follow  are 
intended  to  satisfy  patrol  squadron  information  needs  for 
the  forseeable  future. 

1 .  Maintenance  Management  Requirements 

In  order  to  provide  sufficient  support  to  the 
management  of  maintenance  data,  any  Patrol  Squadron 
information  system  should  provide  the  following  functional 
capabilities. 

1.  Improve  planning  and  execution  of  scheduled  events 
such  as  phased  inspections,  time  limited  component 
replacements,  and  technical  directive  compliance. 

2.  Reduce  the  effort  in  collecting,  converting,  and 
analyzing  flight  activity  and  configuration  data 
required  by  up-line  management  and  the  cognizant  field 
activities  for  aircraft  and  engines. 

3.  Eliminate  manually  maintained  local  forms  for  flight 
activity  records  concerning  aircraft  and  equipment. 
This  should  include  automation  of  the  Naval  Aircraft 
Plight  Record  (yellow  sheet) ,  VIDS/HAF,  and  SAP. 

4.  Automate  the  AIHD  interface  for  equipment 
repair/supply  tracking. 


» 
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5.  Provide  close,  continuous  monitoring  of  the 
availability,  status,  and  usage  of  all  assets. 


6.  Improve  squadron  maintenance  participation,  as 
reporting  custodian,  in  the  configuration  management 
process. 


7.  Provide  more  timely  control  of  configuration  data  by 
tracking  configuration  baselines  in  near  real-time. 


8.  Improve  maintenance  decision  efficiency  by  providing 
rapid  access  tc  a  composite  bank  of  aircraft/engine 
ana  component  compatibility  data. 


9.  Reduce  aircraft/system  damage  occurences  relating  to 
the  aircraft  configuration  management  system. 


10.  Provide  consolidation  of  information  with  operations, 
training,  and  personnel/administrative  functions,  in 
order  to  reduce  redundancy  and  duplication  of  effort. 
This  includes  flight  hour  accounting  data  and  aircrew 
utilization  for  the  Operations  Department,  personnel 
qualifications/status  for  the  Administrative 

Department,  and  numerous  plans,  reports,  and  schedules 
for  the  Training  Department. 


2 .  Operations  Management  Requirements 


Management  of  squadron  operations  requires  a  myriad 
of  skills,  procedures,  and  information  needs.  The  following 


functions  are  essential  elements  of  an  effective  Patrol 


Squadron  information  system. 


1.  Provide  data  concerning  present  and  future 
requirements,  physical  assets,  personnel,  and  training 
in  order  to  plan  long  term  commitments  as  well  as  to 
produce  daily  operational  schedules. 


2.  Provide  timely,  reliable  data  management  information 
for  unit  and  wing  Commanders. 


3.  Provide  yellow  sheet  flight  data  management  and 
logging. 


4.  Track  and  summarize  OPTAR  and  TEEAD  funds,  ordnance 
allocations,  and  expenditures. 


5.  Track  and  control  sonobouy  inventory  and  usage. 
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6. 


Maintain  currant  flight  hour  accounting  (glidepatn) 
iata,  for  use  in  operational  planning  as  well  as 
reporting. 

7.  Provide  access  to,  and  analysis  of,  readiness  figures 
and  trends. 


8.  Provide  dissemination  of  operational  plans,  schedules, 
reports,  and  actions  to  other  functional  areas  in  the 
squadron . 


3.  Training  Management  Requirements 

Patrol  sguadron  training  is  mere  extensive,  more 


time  consuming,  and  requires  more  resources  than  training  in 


most  aviation  squadrons  due  to  mission  complexity,  cross 


training  considerations,  and  crew  size.  Due  to  these 


factors,  the  management  of  training  and  training  information 


is  critical  to  the  successful  execution  of  the  VP  mission. 


The  following  functional  capabilities  are  required  for 
optimum  squadron  performance. 


1.  Eliminate  from  the  planning  and  decision  making 
processes  the  problems  associated  with  the  use  of 
inconsistent  ana  incomplete  training  datg.  by  providing 
a  means  of  preparing  and  presenting  training 
information  in  a  uniform  manner. 

2.  Reduce  the  time  and  volume  of  information  required  to 
make  training  decisions  by  reporting  to  each  level 
only  necessary  degrees  of  detail  and,  when 
appropriate,  only  the  exception  from  the  stsndard  or 
norm . 


3.  Permit  consideration  of  the  effect  of  a  decision  in 
advance  by  supplying  complete,  accurate,  and  timely 
training  data  for  use  in  the  planning  and  decision 
making  process. 


4. 


Schedule  training  resources  (aircraft, 
simulators,  trainers,  personnel,  etc.) 
training  requirements  and  priorities. 


classrooms 
to  meet  tota 


I 


5.  Schedule  training  to  minimize  consumption  of 
resources. 
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6.  Enable  the  use  and  update  of  a  prepared  question  bank 
for  generation  of  testing  materials. 


7.  Support  individualized  instruction  by  allowing 
modification  of  standard  syllabus. 


8.  Enable  authorized  personnel  to  author,  edit,  review, 
and  update  all  training  related  materials. 


9.  Generate  student  gradebooks  to  track  each  aircrew 
members  progress  through  his  training  syllabus. 


10.  Maintain  data  on  military  education  and  advancement. 
Included  in  this  area  are  school  and  qualification 
records,  individuals*  advancement  requirements  and 
progress,  etc.. 


4 .  Personnel/Administrative  Management  Requirements 

Effective  squadron  management  is  facilitated  only  by 


a  tremendous  amount  of  emphasis  on  administative  functions 
and  how  they  relate  to  squadron  personnel.  This  critical 
area  of  squadron  performance  crosses  all  departmental  lines 


and  affects  all  squadron  functions.  The  following 
requirements  are  necessary  for  the  efficient  and  effective 


management  of  personnel/admin  functions. 


1.  Improve  the  timeliness  and  data  quality  of  up-line 
reports  while  reducing  the  man-hours  required  for 
report  preparation. 


2.  Provide  word  processing  capability,  including  output 
of  routine  reports,  letters,  instructions,  etc. 


3.  Facilitate  efficient  management  and  control  of 
military  duty  and  its  associated  accountability 
through  the  maintenance  of  watch  bills,  duty  section 
lists. 


4.  Track  personnel  resource  data,  such  as  Naval  Enlisted 
Classification  codes  (NEC)  ,  gains  and  losses, 
time-in-rank,  time-in-service,  etc.. 
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5 .  Su  irniar 


The  functional  system/user  requirements  that  have 
been  developed  are  certainly  not  exhaustive,  but  are,  as 
iesired,  acre  general  in  nature.  They  do,  however,  cover 
the  entire  functional  range  of  activities  that  a  patrol 
squadron  engages  in.  This  straightforward  approach  to 
requirements  determination  has  produced  the  functional 
criterea  necessary  fcr  comparison  between  alternatives. 

C.  ALTERNATIVE  DEVELOPMENT  AND  REVIEW 
1 .  Assumptions 

Prior  to  the  statement,  discussion,  and  comparison 
of  alternative  courses  of  action  that  confront  decision 
makers,  it  is  necessary  to  illuminate  a  few  assumtions  on 
which  the  analysis  of  these  alternatives  are  based. 

First  of  all,  it  is  assumed  that  Patrol  Squadron 
organization  and  procedures  do  not  differ  significantly  from 
squadron  to  squadron,  and  that  the  squadron  mission  will  not 
change  in  the  near  future.  This  assumption  is,  of  course, 
necessary  in  order  to  consider  any  MIS  responsive  to  the 
needs  of  the  entire  community.  In  fact,  instituting  a  MIS 
in  all  squadrons  will  reinforce  this  assumption,  in  that  it 
will  encourage  community-wide  standardization  of  procedures. 
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Secondly,  system  operational  life  is  assumed  to  be 
independent  of  any  system  developments  currently  ongoing, 
and  is  estimated  to  parallel  the  life  expectancy  of  other 
Navy  general  purpose  ADE. 

Additionaly,  in  order  to  fairly  state  all 
alternatives,  it  is  assumed  that  political  and  regulatory 
considerations  are  net  considered.  Only  after  all  feasible 
alternatives  are  examined  will  these  factors  be  counted. 

As  squadrons  move  between  sites,  the  HIS  must  appear 
identical  to  the  user.  Information  must  be  transferable 
between  sites  in  machine  readable  form.  Therefore,  it  is 
assumed  that  system  compatibility  is  essential  to 
alternative  development. 

The  ability  for  the  system  to  fail  soft  is  another 
assumption  that  is  made.  Even  though  the  probability  of  an 
intermittent  system  or  power  failure  is  low,  the  system  must 
not  preclude  the  return  to  manual  modes. 

Finally,  system  uniqueness  is  not  an  aim  or  an 
assumption  relagated  to  Patrol  Sguadron  HIS  development. 
Any  system  satisfying  the  functional  requirements  will  be 
considered,  whether  or  not  it  was  designed  specifically  for 
the  Patrol  Community.  In  the  same  light,  if  uniqueness  is 
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necessary  zo  meet  the  needs  of  the  community,  then  existing 
alternatives  must  give  way  to  new  ideas. 

2 .  Statement  of  Alternatives 

Stating  alternatives  tc  meet  the  functional 
requirements,  assumptions,  and  user  preferences  can  now  be 
undertaken.  The  development  of  these  alternatives  should 
focus  on  the  degree  of  improvement  that  would  be  possible 
from  the  implementation  cf  a  particular  system.  System 
costs  are,  of  course,  as  important  as  system  benefits,  in 
most  cases.  This  case  is  no  exception,  but  before  any  cost 
factors  can  be  considered,  the  relative  capabilities  of  the 
alternatives  must  be  reviewed  and  compared. 

The  capability  criteria  from  which  comparison  can  be 
made  are  listed  below: 

1.  Management  effectiveness/efficiency 

a.  Maintenance  management  functions 

b.  Operational  management  functions 

c.  Training  management  functions 

d.  Personnel/administrative  functions 

2.  Vulnerability 

a.  Security 

b.  Communications 

c.  Data  backup 
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3.  System  compatibility 

a.  Interface  with  other  systems 

b.  base/deployment  compatibility 

4.  Portability 

In  an  attempt  to  identify  methods  to  meet  the  desired 
capabilities  of  a  Patrol  squadron  8IS,  the  following 
alternatives  have  been  developed.  The  statement  and 

explanation  of  these  alternatives  is  intended  to  provide  the 
reader  with  an  understanding  of  each  proposal,  and  provide  a 
framework  from  which  comparison  can  be  made. 

Alternative  1  -  Continue  with  current  methodology 

Alternative  2  -  Expand  existing  ATSS  resources 

Alternative  3  -  Adapt  NALCOMIS  to  satisfy  VP  needs 

Alternative  4  -  Initiate  development  of  a  completely  new 
system 

Alternative  5  -  Implement  enhanced  PLS  (mini-ATSS)  in 
patrol  squadrons 

a.  Alternative  1 

The  current  squadron  organization  and 
procedures,  as  decribed  in  Chapter  Pour,  have  evolved  over 
th«  years  into  a  system  of  manual  data  entry,  transcription, 
and  research  tasks.  The  continued  growth  in  data  generation 
and  reporting  requirements  will  further  decrease  squadron 
management  efficiency,  relative  to  the  current  situation. 
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An  attempt  to  improve  the  current  system  by 
further  evolution  or  streamlining  of  manual  procedures  will 
not  produce  significant  results.  Manual  tools  are  limited 
in  environments  requiring  more  data  and  near  real-time 
responses  to  inquiries.  [Bef.  17]  Additional  personnel 
could  accomodate  a  growth  in  data  processing  requirements, 
but  that  is  not  a  plausible  solution  in  today's  environment. 
Personnel  resources  are  in  short  supply  in  the  Navy,  and  the 
requirement  for  more  personnel  support  could  mean  less 
personnel  available  for  operational  assignment. 

This  alternative  assumes  that  word  processing 
capabilities  are  available  to  V?  Squadrons  at  present,  some 
squadrons  have  obtained,  or  will  obtain,  word  processing 
equipment  to  handle  routine  correspondence,  reports,  and 
instructions.  Even  with  this  capability,  the  bulk  of 
squadron  functional  requirements,  outside  the  area  of 
administration,  are  not  met. 
b.  Alternative  2 

The  alternative  to  expand  existing  ATSS 
resources  into  Patrol  Squadrons  was  recommended,  in  concept, 
by  Naval  Audit  Service  auditors.  £Bef.  4]  This  action,  if 
taken,  would  only  partially  meet  the  requirements  of  the 


squadrons.  They  would  be  provided  full  functional 
capability  during  at-hone  periods,  but  upon  deployment  would 
be  severed  from  any  automated  information  capability.  Sven 
during  at-home  cycles  the  availability  and  capability  of  the 
ATSS  system  would  be  limited  and  controlled  by  a  centralized 
facility.  With  limited  control,  system  vulnerability  would 
be  affected.  Although  data  backup  could  be  maintained, 
security  of  squadron  files  would  be  questionable,  and 
communication  interruption  would  be  more  probable. 

This  alternative  would  require  a  great  deal  of 
additional  hardware,  not  only  to  provide  squadrons  with 
input/output  capability,  but  also  to  maintain  responsive 
processing  performance. 

Due  to  the  nen-portability  of  existing  ATSS 
systems,  base/deployment  compatibility  of  information 
processing  procedures  would  be  non  existent.  Only  by  future 
expansion  of  ATSS  to  all  deployment  sites  could  this 
compatibility  be  achieved. 

For  these  reasons,  this  alternative  is  not 

acceptable . 
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If  NALCOMIS  nodule  1  development  is  continued  as 
currently  planned,  it  is  feasible  to  consider  the  sharing  of 
these  resources,  adapting  the  system  to  meet  VP  needs. 

The  current  objective  of  the  NALCOMIS  Module  1 
concept  is  to  provide  local  maintenance  and  material 
managers  at  the  OMA,  IMA,  and  SSC  levels  with  a  modern, 
responsive  management  information  system.  As  envisioned,  it 
will  easily  meet  the  maintenance  information  requirements  of 
a  patrol  squadron.  Also,  the  personnel/administration 
functional  capabilities  are  present,  but  would  require 
extensive  modification.  Unfortunately,  applications  are  not 
planned  in  the  areas  of  aircrew  training  and  operational 
control. 

It  is  certainly  within  the  potential  of 
NALCOMIS1  planned  hardware  to  meet  Patrol  Squadron  needs, 
but  the  additional  training  support,  operational  management, 
as  well  as  additional  personnel/admin  application  software 
would  require  expensive,  time-consuming  development. 
Additionaly,  as  pointed  out  in  Chapter  Three,  the  extremely 
slow  implementation  schedule  of  NALCOMIS  is  contradictory  to 
the  basic  underlying  need  of  the  Patrol  Community,  which  is 
a  timely  solution  to  its  information  needs. 


Future  MALCOHIS  development  will  further  dictate 
whether  the  feasible  application  of  this  system  to  VP 
requirements  is  possible.  Current  political  and  econoaic 
factors  will  have  a  huge  impact  on  the  course  of  NALCOMIS 
Module  1  development,  and  could  force  modification  to 
accomodate  other  applications.  At  present,  however,  systea 
design  does  not  support  compatibility  with  existing  VP 
systems,  and  if  implemented  would  be  plagued  by  problems 
involving  information  portability  and  communications 
complexities. 

Due  to  these  factors,  this  alternative  is 
considered  unresponsive  to  Patrol  Sguadrcn  requirements, 
d.  Alternative  4 

Original  development  of  a  system  designed  to 
specifically  address  Patrol  Squadron  requirements  is 
presented  to  ensure  that  no  stones  are  left  unturned  in 
determining  decision  alternatives  available  to  community 
leadership.  The  feasibility  of  this  alternative  is  based  on 
the  fact  that  new  system  developments  can  be  tailored  to 
meet  practically  any  set  of  requirements.  The  cost  of  this 
alternative,  in  teras  of  tine  and  money,  is  a  function  of 
the  extent  of  compatibility  the  systea  will  have  with 
existing  Patrol  Community  systems. 
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System  developments  included  in  this  concept 
could  range  from  a  small  personal  microcomputer  with 
homegrown  software  and  virtually  no  compatibility  with 
existing  systems,  to  a  NALCCMIS-lik e  development  which  would 
be  completely  compatible  with  all  community  systems,  but 
would  require  multi-year  development  and  prohibitive  funding 
requirements. 

It  is  beyond  the  scope  of  this  study  to  identify 
specific  new  system  designs.  Presentation  of  this 
alternative  does,  however,  show  that  new  development  is 
feasible.  Further  investigation  of  new  development  should 
only  be  undertaken  if  it  is  determined  that  no  existing 
developments  or  systems  can  be  utilized.  This  determination 
could  save  commanders  lengthy  system  development  time  and 
could  avoid  the  cost  cf  this  development, 
e.  Alternative  5 

The  Portable  Logistics  System,  as  explained  in 
Chapter  Two,  meets  individual  Patrol  Squadron  requirements 
in  all  categories  of  system  vulverability ,  compatibility, 
and  portability.  By  adding  additional  ATSS  software 
modules,  which  are  already  developed  and  tested,  to  the  PLS 
hardware  configuration,  the  functional  categories  of 
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operational  management,  training  management ,  and 
personnel/administrative  management  can  also  be  satisfied. 

This  concept  will  permit  individual  squadron 
commanders  to  operate  individual,  fully  capable,  turnkey 
systems  at  any  base  or  deployment  site,  while  providing  for 
compatibility  and  interface  with  both  existing  &TSS  sites 
and  operational  maintenance  systems. 

One  of  the  greatest  advantages  of  this 
alternative  is  the  fact  that  virtually  no  hardware  or 
software  development  is  required.  &TSS  software  has  been 
run  on  proposed  PLS  hardware,  and  has  handled  squadron 
workload.  [Hef.  18] 


This  alternative  fully  meets 
forth  by  the  definition  of  requirements, 
considered  most  responsive  to  the  needs 
Community. 

3 .  Comparison  of  Alternatives 
a.  Benefits 

The  alternatives  that  have 
represent  a  wide  range  of  conceptual 
capability  criteria  that  were  used  to 
feasibility  of  each  of  the  alternatives 


the  criteria  set 
and  should  be 
of  the  Patrol 


been  presented 
designs.  The 
establish  the 
are  an  excellent 
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means  of  comparing  the  benefits  of  the  different  ideas 
presented. 

Table  2  illustrates  the  relative  responsiveness 
of  each  alternative  when  compared  on  the  basis  of  system 
objectives.  Each  alternative  is  judged  in  terms  of  the 
individual  objective  areas  and  indicated  by  an  "X"  in  the 
tabular  matrix  if  it  fully  meets  the  individual  requirement. 
If  the  alternative  only  partially  satisfies  an  individual 
capability,  a  "E"  is  indicated  in  the  matrix.  The  areas 
that  are  not  satisfactorily  addressed  or  satisfied  by  the 
alternatives  are  left  blank  in  the  matrix. 

Examination  of  the  table  shows  clearly  which 
alternatives  will  meet  the  objectives  established  by  the 
system  requirements  of  the  user.  Alternatives  Four  and  Five 
are  the  only  proposals  which  fully  satisfy  all  objectives. 

Since  further  differentiation  between 
alternatives  cannot  be  gained  from  analysis  of  requirements, 
other  criteria  should  be  addressed.  The  development  of 
requirements  and  alternatives  has,  by  design,  not  addressed 
the  life  cycle  costs  (LCC)  or  environmental  (political  and 
regulatory)  considerations  associated  with  each  feasible 
alternative.  Ibis  was  done  to  ensure  that  the  most 
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beneficial  system  concept  could  be  envisioned  without 
economic  or  environmental  contamination.  The  results  of 
this  sterile  analysis  have  produced  two  feasible 
alternatives  whose  benefits,  when  examined  in  the  light  of 
real  world  constraints,  are  counter-balanced  by  factors  of 
the  economy  and  the  environment, 
b.  Costs 

A  rigorous  cost-benefit  analysis  comparing 
Alternatives  4  and  5  would  not  be  realistic,  and  therefore 
not  very  beneficial,  at  this  conceptual  stage  of  analysis. 
Some  factors  of  cost  can,  however,  be  addressed  in  order  to 
more  strongly  support  the  feasibility  of  either  alternative. 

If  Alternatives  Four  and  Five  are  examined  in 
terms  of  life-cycle  costs,  it  is  possible  to  visualize  a 
large  cost  differential  between  the  two.  This  can  even  be 
accomplished  without  specifically  defining  what  type  of 
system  Alternative  Four  would  entail. 

With  the  declining  or  stabilized  hardware  costs 
present  in  the  ADP  industry  today,  this  factor  cannot  be 
considered  too  heavily.  Even  so,  it  is  inconceivable  that  a 
newly  developed  turnkey  system,  meeting  VP  squadron  needs, 
could  be  produced  any  more  cheaply  than  the  cost  of  the 
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which  is 


presently 


proposed  PLS  ( mini- ATSS)  hardware, 
estimated  at  less  than  $23,000. 

Software  dewelopaent  is  becoming  lore  and  more 
costly,  entailing  up  to  80*  of  systea  developient  costs, 
[fief.  19]  Alternative  4  would  require  a  full  development 
effort,  whereas.  Alternative  5  would  require  only  minor 
aodification  to  existing  ATSS  software.  This  is  a 
significant  difference  between  the  two  feasible  choices. 

Software  aaintenance  is  another  critical 
life-cycle  factor  whose  cost  snould  be  considered.  Either 
alternative  will  require  maintenance  of  system  and 
applications  software.  ATSS  software  has,  however,  been 
evolvina  for  alaost  ten  years.  It  has  been  constantly 
tested  in  an  operational  environment  and  has  performed  well. 
Newly  developed  software  would  be  untested,  and  even  if 
reliable  from  the  start,  would  require  no  less  aaintenance 
than  existing  programs. 

Other  life-cycle  costs,  including  site 
preparation,  implementation,  user  training,  and  hardware 
aaintenance  must  be  considered  fairly  equal  between 
alternatives  as  well. 
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Because  of  the  life-cycle  estimates,  Alternative 
5  is  considered  a  considerably  sore  desirable  developmental 
path. 

c.  Environment 

Chapter  Three  discussed  political  and  regulatory 
considerations  at  length.  Comparing  alternatives  in  these 
terms  is  extremely  difficult  due  to  the  uniqueness  of  each 
ADP  acquisition.  A  decision  to  pursue  Alternative  4  would, 
of  course,  require  a  full  developmental  effort.  Only 
through  a  detailed  analysis  of  this  particular  concept  could 
an  acquisition  strategy  be  proposed.  The  PLS  (mini-ATSS) 
concept  has,  however,  been  evolving  over  a  two  year  period. 
Its  applicability  to  Patrol  Aviation  has  been  completely 
ignored  until  new.  As  mentioned  earlier,  the  political 
environment  surrounding  ADP  procurement,  especially  in  Naval 
Aviation  circles,  is  very  dynamic.  The  Eeagan 
administration  has  stated  its  interest  in  simplifying  the 
systems  acquisition  as  well.  Thresholds  for  purchase  of 
non-tactical  systems  with  Type  Commanders'  Operation  and 
Maintenance  (OSH)  funds  are  evolving,  which  could  make  it 
possible  for  operational  units  to  acquire  the  needed 
systems.  What  is  critical  in  examining  the  environmental 
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factors  affecting  a  given  alternative,  is  that  if  the 
alternative  is  most  feasible  is  terns  of  its  cost 
effectiveness,  it  should  be  pursued  in  a  whatever  manner 
possible,  regardless  of  the  current  political  or  regulatory 
situation. 

D.  CHAPTER  SUMMARY 

The  development  of  an  enhanced  version  of  the  Portable 
Logistics  System,  which  the  authors  refer  to  as  "Hini-AISS" , 
has  evolved  from  this  chapter  as  the  most  feasible,  logical, 
cost-efficient  method  of  filling  the  information  system  void 
existing  in  the  Patrol  Aviation  Community.  This 
developmental  path  is  based  on  satisfaction  of  the 
user/system  requirements  that  were  developed.  The 
requirements  established  in  the  chapter  were  developed  from 
data  and  perceptions  obtained  from  squadron  personnel 
currently  involved  in  the  operational  environment  as  well  as 
from  the  experience  and  perceptions  of  the  authors.  These 
requirements  are  the  building  blocks  from  which  any  squadron 
system  must  be  derived,  and  should  be  refered  to  constantly, 
no  matter  what  developmental  path  is  eventually  chosen. 
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VI.  CONCLUSIONS  AND  RSCOMMI NDATIOMS 


The  Patrol  Aviation  Community  has  net  fully  recognized 
the  need  for  automated  management  information  system  support 
at  the  squadron  level.  Reviewing  historical  and  current  MIS 
development  in  Naval  Aviation  has  shewn  that 
technologically,  the  decision  by  commanders  to  obtain 
automated  information  resources  to  assist  in  management  is 
well  overdue.  Feasible  systems  have  been  proposed, 
developed,  and  implemented  in  some  sectors  of  Naval 
Aviation,  but  have,  thus  far,  excluded  Patrol  Sguadron 
applications.  This  is  partially  attributable  to  current 
political  and  economic  factors,  but  is  also  a  function  of 
Patrol  Aviation's  inattention  to  the  problem. 

Current  squadron  organization  and  procedures  are  plagued 
by  information  deficiencies  in  almost  all  functional  areas. 
These  deficiencies  translate  into  a  valid  need  for  automated 
information  support  which  will  increase  leadership's 
effectiveness  in  both  training  and  operational  environments. 

The  analysis  of  squadron  requirements  points  out  very 
clearly  that  currently  approved  Naval  Aviation  MIS 
developments  which  do  include  planned  support  for  VP 
Squadrons  are  primarily  concerned  only  with  maintenance 
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functions.  They  will  net  .-tisty  the  operational,  training, 
and  administrative  requirements  of  an  individual  squadron. 

Initiatives  that  will  satisfy  squadron  reguireaents  do 
exist.  Offspring  of  ATSS,  initially  developed  by  NAVWPNCEM, 
could  completely  satisfy  community  needs.  The  Portable 
Logistics  Systea,  enhanced  with  Automated  Training  Support 
Systea  software  aodules  (Mini-ATSS)  ,  conceptually  appears  to 
be  the  most  feasible  alternative  available  to  the  community. 

When  compared  in  terms  of  life-cycle  costs  with  the 
alternative  of  a  new  developmental  effort,  Mini-ATSS  is  much 
more  cost-effective.  This  is  primarily  due  to  the  software 
development  costs  that  could  be  forgone. 

Hardware  costs  can  be  put  in  perspective  with  an 
illustration  of  their  compatibility  to  other  squadron 
expenditures.  Proposed  PLS  hardware,  which  would  more  than 
satisfy  Mini-ATSS  requirements,  has  a  current  purchase  cost 
of  less  than  $23,000.  In  comparison,  each  squadron  owns  18 
HF  radios  that  ccst  approximately  $93,000  each,  but  fail 
frequently.  More  significantly,  P-3  flight  hour  costs  are 
currently  over  $1000  per  hour  just  for  fuel  and  lubricants. 
With  an  average  daily  flight  schedule  of  approximately  25 
hours,  Mini-ATSS  could  be  acquired  for  less  than  one  day’s 
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fuel  requirement.  The  management  efficiency  and  operational 
control  gained  from  the  implementation  of  an  autonated  ms 
would,  however,  prove  far  more  valuable  than  a  single  day's 
flight  hour  allocation,  ultimately  saving  the  squadron  a 
significant  amount  of  time  and  money. 

The  regulatory  environment  surrounding  ADP  acquisition 
will,  in  all  estimation,  dictate  the  availability  and 
acquisition  strategy  used  in  pursuing  this  alternative.  Due 
to  this  situation,  strong  support  from  community  leadership 
is  required  to  bring  about  changes  in  perception  and 
regulation. 

It  is  recommended  that  the  Patrol  Aviation  Community 
make  a  stronger  commitment,  both  politically  and  monetarily, 
to  automation  of  squadron  operational,  training, 
maintenance,  and  administrative  management. 

It  is  critical  that  community  leadership  receive  more 
and  better  education  with  respect  to  capabilities  available 
through  the  use  of  automated  management  information  systems. 

Further  study  should  be  directed  toward  an  acquisition 
strategy  that  will  provide  the  most  cost-effective  solution 
to  meet  the  squadron  information  requirements  developed  in 


this  thesis 


These  actions  are  essential  to  the  further  iaprovement 
of  squadron  performance,  efficiency,  and  readiness,  and  will 
ultinately  bear  significantly  on  Patrol  Aviation's  continued 
contribution  to  national  defense. 
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